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I.  INTRODUCTION 

This  report  is  prepared  under  Naval  Air  Systems  Command  Contract  N00019-96- 
C-2040  and  summarizes  the  investigation,  findings,  solutions,  and 
recommendations  provided  by  Dual,  Incorporated  (Dual)  personnel  during  the  27 
June  to  27  November  1996  time  period.  This  project  is  a  Phase  I  effort  of  the 
Small  Business  Innovation  Research  (SBIR)  Topic  N96-053  of  Naval  Air 
Systems  Command.  This  document  is  the  final  report  submitted  for  the  project. 

The  original  scope  of  this  investigation  was  to  identify  a  cost  effective  approach 
towards  developing  an  interface  unit  used  to  facilitate  the  timely  transfer  of 
Operational  Flight  Program  (OFP)  software  (Tactical  Tapes)  from  aircraft 
software  support  activities  to  the  respective  aircrew  simulators.  In  the  current 
training  environment,  maintaining  the  functional  concurrency  of  the  training 
device’s  computer  driven  aircraft  hardware  with  the  parent  aircraft  is  a  costly  and 
time  consuming  effort.  Presently,  transition  of  new  or  modified  data  from  aircraft 
to  cockpit  simulators  require  redundant  or  overlapping  development  efforts  by 
the  weapon  software  and  trainer  software  support  engineers.  When  training 
devices  are  not  in  the  same  revision  configuration  as  the  aircraft,  training 
sessions  are  less  effective,  since  the  displays  and/or  aircraft  responses  may  not 
be  consistent  with  what  will  be  observed  in  the  aircraft  cockpit.  The  negative 
training  resulting  from  not  maintaining  aircraft  to  trainer  concurrency  can  include 
poor  mission  performance  or  even  catastrophic  events. 

II.  PHASE  I  OBJECTIVES 

The  objective  of  this  SBIR  is  to  investigate  and  identify  a  cost  effective  approach 
for  the  transfer  of  new  or  updated  OFP  and  related  software  from  the  developer 
activity  to  the  aircrew  simulators. 

During  this  Phase  I  effort,  Dual  has  focused  on  the  Navy  F-14  aircrew  training 
devices,  as  directed  by  the  sponsor.  Additionally,  our  investigation  sought  to 
identify  methods  used  by  other  training  device  users  that  may  prove  germane  to 
moving  OFP  data  from  its  origin  to  the  end  user,  and  rendering  this  information 
usable  in  training  devices. 
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III. 


Specific  Phase  I  Technical  Objectives  are  as  follows: 

1 .  To  determine  functional  requirements  of  a  standard  interface  unit 
for  the  “simulation”  and  “stimulation”  approaches. 

2.  To  identify  current  or  evolving  technologies  to  be  used  to 
accomplish  the  task. 

3.  To  identify  hardware  and/or  software  development  required  to 
accomplish  the  task. 

4.  To  define  the  technical  design  requirements  of  the  interface  unit. 

o  analyze  the  feasibility  of  developing  an  interface  unit  and/or 
process  to  accomplish  the  task. 


WORK  PERFORMED 

Figure  III-1  presents  the  overall  milestones  for  the  project.  Dual’s  first  task  was 
to  determine  the  current  methods  used  in  the  training  community  to  accomplish 
rainer  upgrades  and  commonality  between  the  actual  operational  equipment 
Our  data  search  included  Navy,  Air  Force  and  NASA  training  devices  The 
purpose  was  to  assess  the  current  state  of  the  art  and  identify  methods  that 
could  be  applied  to  Navy  training.  In  parallel  with  our  visits  and  general  inquiries 
a  search  was  commenced  for  literature  with  reference  to  Operational  Flight 
Progranns  and  the  problems  of  portability  to  training  devices,  and  the  networking 
or  transfer  of  data  between  computers.  The  U.S.  Department  of  Commerce’s 
National  Technical  Information  Service  database  was  consulted  and  a  number  of 
report  summaries  as  well  as  full  reports  were  reviewed. 

The  investigation  began  with  site  visits  to  several  Naval  Air  Warfare  Center 
facilities  including  the  Training  and  Simulation  Division  (NAWCTSD)  in  Orlando 

^ Simulator  (MFS)  group  in  Patuxent  River,  Maryland,’ 
and  the  F-14  Trainer  Software  Support  Activity  (TSSA)  at  Pt.  Mugu,  California. 

At  NAWCTSD  information  was  obtained  on  F-14  aircrew  training  devices,  their 
locations,  and  an  overview  of  the  trainer  software  support  system.  Through  their 

^  containing  data  on  Device 

2F169  which  the  Grumman  Corporation  is  currently  modifying  from  the  F-14D  to 
F-14B  configuration. 

The  Visit  to  Manned  Flight  Simulator  (MFS)  resulted  in  the  SBIR  Sponsor 
providing  additional  guidance  on  the  direction  that  this  investigation  should 
progress^  It  was  noted  that  the  last  tactical  tape  upgrade  for  the  F-14D  cost  over 
3  million  doHars.  with  an  additional  1.3  million  to  clear  the  major  discrepancies 
that  resulted  in  that  upgrade.  The  primary  goal  of  this  investigation  should  be  to 
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provide  recommendations  on  streamlining  the  overall  trainer  upgrade  process 
and  determining  how  to  save  money  on  future  trainer  updates.  The  identification 
of  a  specific  hardware  solution  may  not  be  of  prime  importance  at  this  time. 
Rather,  a  cost  effective  system  concept  for  the  trainer  software  upgrade  process 
must  be  defined.  At  this  point,  our  investigation  shifted  from  a  purely  tactical 
tape  transfer/software  modification  problem,  to  an  overall  trainer  system  upgrade 
concept.  The  MFS  Project  Support  Team  Leader,  who  played  a  major  role  in 
building  the  AH-1W  Aircrew  Procedure  Trainer  (APT)  currently  installed  at  Camp 
Pendleton,  briefed  Dual  on  the  role  of  MFS  in  simulator  design,  and  provided  an 
overview  on  the  AH-1W  simulator.  MFS  is  currently  building  two  more  APTs  for 
delivery  to  the  Marine  Reserves  in  Atlanta  and  New  Orleans. 

Atthe  F-14  TSSA  in  Pt.  Mugu,  Dual  received  an  extensive  briefing  concerning 
the  mission,  recent  activities,  and  tour  of  the  Trainer  Software  Design  Facilitv 
(TSDF).  ^ 

Dual  expanded  it’s  inquiry  to  other  organizations  to  determine  if  techniques 
applicable  to  trainer  software  concurrency  were  used  elsewhere.  Through  our 
Dual-Houston  office  and  a  personal  visit  to  Houston,  information  was  obtained 
from  NASA  about  the  methods  used  to  maintain  currency  between  the  Shuttle 
Mission  Simulators  and  the  actual  space  hardware.  The  Air  Force  Agency  for 
Modeling  and  Simulation  provided  information  on  the  F-16  trainer  program  based 
at  Hill  AFB  and  provided  a  configuration  management  manual  for  F-16  series  of 
training  devices. 

Once  the  literature  review,  data  collection,  discussions  with  designers,  users  and 
key  management  personnel  were  accomplished,  the  data  was  assessed  to 
identify  the  general  and  unique  functional  requirements  that  an  interface  unit  or 
process  would  need  to  address  in  order  to  support  the  overall  goal  of 
streamlining  the  aircraft  to  trainer  upgrades. 


IV.  RESULTS  OBTAINED 

A.  Subject:  Navy  F-14  Aircraft/Simulator  Deployment  -  Dual  sought 
information  on  the  current  and  future  locations  of  the  target  aircraft  and 
simulator  communities  in  order  to  access  the  communication  and  trayel 
requirements  needed  to  support  the  change  and  testing  process. 

Results:  The  WSSA  that  supports  the  F-14  Aircraft  changes  is  located  at 
Pt.  Mugu,  California.  The  TSSA  that  supports  the  F14  suite  of  trainers  is 
also  located  at  Pt.  Mugu.  The  trainers  supported  are  the  Mission  Trainer 
(15C9A),  Operational  Flight  Trainer  (2F95),  Mission  Flight  Trainer 
(2F153),  Weapon  Systems  Trainer/Tactical  Environment  System  (2F154), 
and  the  Weapons  Systems  Trainer(2F169).  Locations  for  these  trainers 
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currently  include  Ft.  Worth,  Texas;  Miramar,  California;  Pt.  Mugu, 
California;  Oceana,  Virginia,  Patuxent  River,  Maryland,  and  Atsugi, 

Japan.  Dual  was  briefed  on  the  plans  for  re-deployment  of  the  Navy’s  F- 
14  aircraft  and  trainers.  By  14  November  1996,  all  of  the  Navy’s  F-14s 
will  have  executed  a  homeport  change  to  NAS  Oceana.  Fighter  Wing 
Pacific  will  be  formally  decommissioned  on  16  December  1996.  The 
current  plans  include  some  variant  of  the  F-14  aircraft  remaining  in  service 
through  Fiscal  Year  2010.  The  present  configurations  of  the  F-14  aircraft 
include  the  “A”,  “B”,  “B  Upgrade”,  and  “D”  models.  There  are  eleven  F-14 
squadrons  and  a  training  squadron  (VF-101)  stationed  at  NAS  Oceana 
and  a  single  F-14A  Squadron  (VF-154)  permanently  deployed  to  Japan  in 
support  of  the  USS  Independence.  Three  of  the  eleven  squadrons,  VF-2, 
VF-1 1  and  VF-31  will  fly  the  “D”  model  aircraft.  Due  to  a  lesser  number  of 
“D”  model  aircraft,  and  pending  aircraft  rework  initiatives;  composite 
squadrons  consisting  of  8  “B”  and  6  “D”  model  aircraft  each  will  be  formed 
commencing  in  Fiscal  Year  1998.  These  squadrons,  VF-2,  VF-11,  VF-31, 
VF-1 43  and  VF-1 02,  while  having  relatively  similar  airframes,  will  be 
considerably  different  from  an  avionics  and  weapons  system  perspective. 
In  this  manner,  the  Pilot  and  Radar  Intercept  Officer  (RIO)  will  be 
challenged  to  maintain  currency  in  two  considerably  different  aircraft 
weapons  systems  operations.  Squadron  VF-1 4  will  commence  the 
transition  to  the  F/A-18E  in  Fiscal  Year  2000,  with  all  remaining  F-14 
transitions  completed  to  the  F-1 8F  by  Fiscal  year  2010.  Refer  to 
Appendix  A  for  a  table  showing  planned  F-14  aircrew  simulator 
deployment. 

Conclusion:  The  TSSA  at  Pt.  Mugu  currently  provides  baseline  and 
change  support  for  five  types  of  trainers  in  six  different  locations 
throughout  the  United  States  and  Japan.  Planned  relocation  of  simulators 
will  bring  the  number  of  simulator  locations  to  three,  with  the  Pt.  Mugu 
TSSA  location  bringing  the  total  of  remote  locations  to  four.  Collocation  of 
the  TSSA  with  the  WSSA  facilitates  coordination  of  changes  and  work  in  a 
WSSA/TSSA  team  environment.  Considering  the  remote  locations  of 
trainers,  and  the  different  types  of  simulators,  an  automated  configuration 
management  tool  with  the  capability  to  store  ail  the  trainer  software  on¬ 
line,  along  with  the  ability  to  move  data  rapidly  from  TSSA  to  the  trainer 
would  be  a  desirous  goal. 

B.  Subject:  Literature  Search  -  A  search  was  conducted  for  literature 

pertaining  to  training  systems  engineering,  problems  of  OFP  portability  to 
training  devices,  and  networking/transfer  of  this  data.  The  U.S. 
Department  of  Commerce’s  National  Technical  Information  Service 
database  was  consulted  and  a  number  of  report  summaries  as  well  as  full 
reports  were  reviewed. 
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Result:  Most  of  the  papers  found  within  the  database  were  directed 
towards  implementation  of  synthetic  battlefield  simulation.  Methodologies 
addressed  better  modularization  and  object  definitions  of  elements  of  the 
synthetic  battlefield,  more  efficient  means  of  task  distribution  among 
networked  simulators,  and  improved  network  topologies.  Additional 
research  was  conducted  at  the  University  of  Central  Florida  Library;  again 
the  information  obtained  was  generally  oriented  to  meeting  selected 
business  objectives,  such  as  intranets. 

Conclusion:  The  topic  of  streamlining  software/system  updating  relating 
to  OFP  portability  has  not  been  researched  (and  reported)  in  any 
substantial  manner. 

C.  Subject:  Marine  Corps  AH-1W  Helicopter  Simulator 

Approach-  The  AH-1W  APT  is  a  new  design.  Dual  sought  to  determine 
the  latest  trainer  design  approaches  used  by  the  Navy  to  better 
understand  what  has  worked,  and  seek  ideas  about  the  aircraft  to  trainer 
concurrency  issue  from  subject  matter  experts.  MFS  personnel  briefed 
Dual  on  the  AH-1 W  simulator.  Also,  a  set  of  questions  (see  Appendix  B) 
was  sent  to  the  MFS  point  of  contact  which  opened  a  continuing  dialog. 

Results:  The  AH-1  W  APT  was  designed  using  the  maximum  amount  of 
commercial  off  the  shelf  items,  and  was  developed  without  the  restriction 
of  military  standards  (see  Appendix  C  for  trainer  block  diagrams).  The 
APT  software  is  block  structured,  and  organized  by  directory.  Of 
particular  interest  was  a  reference  made  that  APT  software  updates  had 
been  transferred  via  modem  from  the  development  facility  at  Patuxent 
River  to  the  trainer  site  at  Camp  Pendleton  and  that  a  software 
configuration  management  tool  was  being  utilized  for  engineering  change 
tracking  and  control.  The  AH-1W  simulators  use  the  “hybrid”  design 
approach  (see  Appendix  D  for  a  discussion  of  trainer  design  approaches). 
A  set  of  actual  aircraft  computer  hardware  is  “stimulated”  by  the  host 
computer  through  an  interface  system,  with  other  black  box  functions 
emulated  by  software  residing  strictly  within  the  host  computer.  APT  1 
has  five  black  boxes,  and  APT  2  has  eight  black  boxes  that  contain 
software  programs.  These  boxes  are  initially  procured  with  the  latest 
version  of  software  available,  and  are  updated  prior  to  delivery  of  the 
trainer  if  needed.  The  OFP  data  on  the  black  boxes  is  maintained  by  the 
AH-1  W  Weapon  System  Software  Activity  (WSSA)  at  NAWCWD,  China 
Lake;  while  the  Trainer  Software  Support  Activity  (TSSA)  for  the  Aircrew 
Procedure  Trainer  is  located  with  the  first  delivery  device  at  Camp 
Pendleton.  The  method  used  by  MFS  to  obtain  new  OFP  data  on  the 
black  boxes,  is  to  return  the  units  to  the  WSSA  where  the  software  is 
loaded  and  then  are  sent  back  to  MFS.  Once  the  trainer  is  fielded  the 
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TSSA  undertakes  this  responsibility.  When  software  updates  to  the  black 
boxes  have  occurred,  no  software  or  hardware  modifications  were 
required  by  MFS  to  the  APT  host  or  black  boxes.  Dual  requested 
clarification  on  the  movement  and  support  of  OFP  or  other  software  from 
MFS  to  the  APT1  at  Camp  Pendleton  via  remote  data  link.  Dual  was 
advised  that  the  process  previously  understood  to  be  a  feature  of  the 
trainer  design  was  actually  a  one  time  occurrence,  and  not  the  normal 
mode  of  operation.  The  only  time  anything  similar  to  this  process 
occurred  was  during  the  course  of  the  APT  1  installation.  The  MFS 
personnel  used  a  modem  and  a  terminal  emulator  to  log  on  to  the  host 
computer,  edit  a  file,  and  then  compile  and  link  with  the  main  program.  At 
no  time  was  OFP  data  manipulated  or  transferred  in  this  manner. 

Conclusion:  The  AH-1 W  trainer  has  many  unique  instructional  and 
design  features,  however,  the  basic  design  is  a  standard  hybrid  approach. 
No  special  method  or  capability  was  included  in  the  trainer  design  that 
would  allow  for  the  movement  of  OFP  or  program  data.  The  tactical  tape 
loading  of  trainer  black  boxes  is  currently  performed  by  the  WSSA  on  an 
as  needed  basis  at  the  China  Lake  facility.  Although  no  host  software 
changes  were  required  to  accommodate  the  last  several  black  box  OFP 
updates,  it  was  unknown  if  future  changes  to  them  would  be  necessary. 

D.  Subject:  NASA  Space  Shuttle  Simulator  Design  Approach  NASA 
was  questioned  about  the  methods  used  to  maintain  currency  between 
the  Shuttle  Mission  Simulators  and  the  actual  space  hardware.  Were 
there  any  use  of  data  links,  or  special  methods  to  move  OFP  type  data  or 
other  software  modifications  quickly  from  the  Shuttle  Software  Support  to 
the  simulators? 

Results:  NASA  uses  its  simulators  not  just  in  training  roles,  but  also  as 
engineering  test  beds.  When  a  new  mission  is  to  be  supported,  any 
changes  to  hardware  or  software  are  tested  on  the  simulators  thoroughly 
before  any  modifications  to  the  actual  equipment  are  authorized.  In  this 
manner,  it  is  the  actual  hardware  that  attempts  to  keep  up  with  the 
simulator’s  changes,  instead  of  the  normal  process  of  the  simulator 
lagging  the  operational  equipment.  Therefore,  any  need  of  rapid  trainer 
software  updates  is  not  necessary. 

Conclusion:  The  NASA  example  cited  is  the  same  as  that  of 
“Engineering  Simulators”  in  the  military.  Usually  a  Weapon  System 
Software  Activity  will  have  an  engineering  simulator  with  which  to  develop 
new  software  or  check  out  hardware  modifications  prior  to  introduction  to 
the  fleet.  The  engineering  simulators  do  not  serve  the  same  purpose  as 
the  training  simulators,  hence  their  design  is  often  quite  different.  Training 
simulators  use  approximation  methods  and  other  “short-cuts”  in  design. 
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Often  updates  to  OFF  data  or  host  software  simulations  are  not  suitable 
for  direct  use  from  one  to  another.  This  approach  was  ruled  out  for  further 
study  because  the  simulators  are  updated  prior  to  modifying  the  actual 
flight  hardware,  and  no  special  data  transfer  or  conversion  methods  for 
this  process  were  identified. 

E.  Subject:  Air  Force  F-16  Simulator  Change  Process-  The  F-16  is  a 
mature  design.  Dual  sought  to  determine  the  current  processes  used  by 
the  Air  Force  to  perform  trainer  update,  and  to  determine  if  any  new 
standards  or  procedures  were  available  across  various  F-16  training 
devices. 

Results:  The  response  from  the  Air  Force  was  that  no  standard  for 
trainer  updates  existed  across  all  simulators  in  its  inventory.  However,  the 
F-16  community  did  provide  Dual  with  a  document  titled  F-16  A/B 
AIRCREW  TRAINING  DEVICES  (ATD1  OPERATIONAL/SUPPORT 
CONFIGURATION  MANAGEMENT  PROCEDURES  (O/S  CMP1  REV  I 
dated  15  January  1992  (see  Appendix  E).  This  document  details  the 
basic  management  and  configuration  control  procedures  used  to  support 
the  computer  resources  on  the  F-16  training  simulators.  An  emphasis  is 
placed  on  the  identification,  tracking,  solution,  and  oversight  of  problems 
and  upgrades  on  the  trainer  system  including  the  delegation  of  specific 
configuration  control  responsibilities  to  the  Trainer  Software  Support 
Center  (TSSC)  and  individual  trainer  sites.  Figure  4-1,  page  20,  of  the 
manual  (see  Appendix  E)  depicts  an  overview  of  the  process  used  to 
effect,  track,  and  implement  changes  to  the  trainer  software. 

Requirements  Reporting  (block  4.1)  is  where  the  change  process  begins. 
Operational  changes  to  the  aircraft,  new  training  requirements  and 
deficiencies  are  identified  by  the  aircraft  program  manager,  the  field 
commands,  and  the  trainer  support  elements.  These  changes  are 
evaluated  for  relevance  to  the  Aircrew  Training  Device  (ATD)  by  the  F-16 
Product  Team  (block  4.2)  with  assistance  from  the  TSSC.  Changes  that 
potentially  impact  the  ATD  are  evaluated  for  cost  impact,  priority  and  are 
assigned  numbers  for  tracking  purposes.  Emergency  and  Urgent  Priority 
changes  (block  4.3)  are  immediately  tasked  to  the  TSSC  and  are 
coordinated  by  phone  or  message.  Changes  of  a  routine  nature  are 
evaluated  as  either  being  design  related  or  attributed  to 
coding/implementation  errors.  The  F-16  Product  Team  also  prepares  and 
distributes  a  quarterly  newsletter  to  ATD  users  regarding  changes  and 
plans.  The  Weapon  System  (Trainer)  Users  Group  (WSTUG)  (block  4.5) 
is  attended  by  both  end  users  and  the  F-16  Project  Team/TSSC.  The 
purpose  of  the  WSTUG  is  to  allow  the  Project  Team  and  TSSC  to  relay 
the  impact  of  identified  changes  to  the  device  users,  to  provide  responses 
the  inquiries  received  from  user  review  of  the  quarterly  newsletters,  and  to 
assist  the  users  in  screening,  prioritizing,  and  establishing  a  candidate  list 
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for  block  upgrades.  The  users  are  responsible  for  informing  the  F-16 
Product /TSSC  team  of  the  need,  priority,  and  implementation  method 
desired  for  the  identified  changes.  Routine  changes  are  delegated  as 
candidates  for  the  annual  block  upgrade  process,  or  are  sent  to  the  TSSC 
as  temporary  changes  until  they  can  be  incorporated  into  the  block 
upgrade  at  a  later  time  if  needed.  Once  changes  are  identified  and 
agreed  to  by  the  WSTUG,  they  are  forwarded  to  the  Configuration  Control 
Boards  (block  4.6)  for  final  approval.  The  TSSC  (block  4.7)  is  now  tasked 
with  implementing  the  approved  temporary  changes  that  have  been 
determined  to  be  in  scope  of  their  organizational  mission.  The  TSSC  is 
charged  with  maintaining  the  product  baseline  and  distributing  the 
temporary  changes  to  the  field  unit  via  magnetic  media,  to  include 
installation  instructions.  Temporary  changes  do  not  require  baseline 
documentation  changes,  however  these  will  be  included  and  documented 
in  block  upgrades.  The  TSSC  is  also  responsible  for  providing  software 
baselines  and  documentation  to  outside  contractors  that  are  servicing  the 
block  upgrade  changes  at  the  direction  of  the  F-16  Product  Team.  The 
TSSC  participates  in  the  design,  in-process  document  reviews,  program 
management  reviews  and  validations  of  block  upgrade  activities  (when 
performed  by  a  contractor  other  than  the  TSSC’s  current  contract 
company).  Once  a  block  upgrade  is  complete,  the  TSSC  is  responsible 
for  the  integration/retrofit  of  temporary  changes  that  occurred  during  the 
interim  build  cycle,  and  to  assure  that  all  documentation  and  software  is 
updated,  distributed,  and  configured.  The  trainer  changes  that  were 
delegated  to  block  upgrades  are  accomplished  under  a  separately 
procured  modification  (block  4.8)  cycle  that  is  scheduled  annually.  These 
chariges  are  competitively  bid,  and  once  the  contracts  are  awarded,  are 
monitored  by  the  F-16  Product  Team  in  conjunction  with  the  TSSC.  Once 
complete,  all  baselines  and  documentation  are  returned  to  the  TSSC  for 
configuration,  inclusion  of  authorized  temporary  changes,  and  distribution 
to  the  field  units.  Throughout  the  previously  described  process  the  F-16 
Product  Team  is  responsible  for  the  tracking  of  change  requests  relative 
to  status,  approvals  of  trainer  software  including  the  digital  land  mass 
radar  and  visual  databases.  Since  portions  of  the  F-16  computer  program 
software  are  classified  up  to  and  including  Secret,  the  F-16  WST  and 
TSSC  operation,  including  lOS  displays  and  hardcopy  printouts  are 
considered  classified  until  reviewed  for  unclassified  determination. 
Coordination  of  changes  via  telephone  requires  the  availability  of  STD  III 
equipment  using  the  Defense  Switched  Network  (DSN),  and  AUTODIN  for 
transfer  of  text  messages. 

While  analyzing  the  software  support  approach  used  by  the  Air  Force,  we 
were  advised  that  the  Unit  Training  Devices  (UTDs)  were  designed 
without  the  aircraft  operational  (mission)  computer.  Through  close 
coordination  between  the  aircraft  and  trainer  design  organizations,  the 
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aircraft  software  is  written  in  Jovial  and  translated  to  Ada  for  application 
directly  to  the  trainer  host  computer.  This  concept  has  been  expanded 
now  to  include  maintenance  trainers. 

Conclusion:  The  method  currently  used  by  the  Air  Force  provides  a 
coordinated  procedure  for  the  identification,  tracking,  authorization, 
implementation,  and  baseline  control  of  changes  to  the  F-16  aircraft 
trainers.  The  various  user  facilities  and  engineering  elements  are  in 
separate  locations  throughout  the  US  and  at  world  wide  NATO  sites 
requiring  secure  communications  capability  for  data  and  voice 
transmissions  for  TSSC  to  trainer  site  coordination  activities.  Tracking 
and  control  of  baseline  is  done  using  computer  based  lists  and  magnetic 
media  data  is  hand  carried.  The  approach  used  on  the  UTDs  would  be 
worth  investigating  further  for  possible  application  to  new  aircrew  trainers. 

Subject:  Navy  F-14  Fighter  Simulator  Design  Approach-  Dual  sought 
to  assess  the  original  design  approach  and  obtained  background  data  to 
better  understand  the  complexities  faced  by  the  TSSA  organization  and 
contractors  in  performing  the  routine  maintenance  and  upgrade  activities 
of  these  devices. 

Results:  Dual  reviewed  the  Software  Design  Document  and  Trainer 
Engineering  Design  Document  for  the  F-14B  trainer  (Device  2F169)  that 
the  Grumman  Corporation  is  presently  converting  from  an  F-14D 
configuration.  The  F-14B  trainer  uses  a  hybrid  design  approach.  The 
aircraft  on-  board  computer  is  stimulated  by  the  host  computer  through  a 
Digital  Conversion  Equipment”  or  DCE.  The  DCE  serves  as  the  prime 
interface  for  moving  data  to/from  the  host  to  the  GFE  equipment.  The 
design  rationale  mentioned  in  the  TEDR  for  using  the  hybrid  approach 
...“was  largely  due  to  the  F-14B  WST  requirement  to  stimulate  the  5400B 
CEM  On  Board  Computer,  thus  providing  the  WST  with  tactical  tape  drop 
in  capability”.  Included  within  the  trainer  functionality  was  a  Radar 
Simulator  System  (RSS).  This  device  runs  separately  from  the  host 
computer,  and  utilizes  Defense  Mapping  Agency  digital  terrain  data  for  its 
operation.  Reference  was  also  made  to  a  Database  Maintenance 
Subsystem  (DMS)  on  the  trainers.  Additional  information  was  obtained  at 
the  TSSA  concerning  the  design  approach  of  other  F-14  trainers.  (See 
Appendix  F  for  examples  of  trainer  block  diagrams). 

Conclusion:  The  F-14  family  of  trainer  design  is  a  standard  hybrid 
design  approach.  No  method  or  capability  was  include  in  the  trainer 
design  that  would  allow  for  the  movement  of  OFP  or  program  data  from 
the  TSSA  to  the  simulator  sites.  From  design  information  obtained  it  was 
noted  that  a  “drop  in  tape”  capability  was  desired,  but  from  discussions 
and  information  gathered  on  current  upgrade  processes,  this  does  not 
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occur  without  significant  host  software  modification  efforts.  In  addition  to 
the  OFP  and  host  software  data  used  on  the  trainers,  the  presence  of 
other  subsystems  such  as  the  Radar  System  Simulator,  and  visual  system 
databases  would  be  candidates  for  a  new  change  control  and  distribution 
process. 

G.  Subject:  Navy  F-14  Trainer  Software  Support  Activity  Overview  - 

Dual  sought  to  determine  the  role  and  responsibility  of  the  TSSA  in  the 
support  of  the  trainer  change  process. 

Results:  Dual  received  a  briefing  at  the  Pt.  Mugu  TSSA.  Refer  to 
Appendix  G  for  an  overview  of  the  TSSA  mission.  The  TSSA  primary 
functions  are  In-Service  Support  that  includes  software  configuration 
management  and  documentation  control,  and  technical  coordination. 
Trainer  Software  Development  Support  consists  of  evaluating  proposed 
contractor  changes,  monitoring  contractor  compliance,  reviewing  software 
documentation,  and  performing  in-plant/acceptance  testing.  Prime 
responsibilities  are  to  “establish  and  maintain  the  Navy’s  capability  to 
implement  approved  software  changes.”  TSSA  incorporates  new  tactical 
software  loads  into  the  on-board  processors,  interfaces  the  processors 
and  host  computer  software,  and  ensures  new  tactical  software 
functionality.  Responsibilities  include  providing  new  trainer  capabilities, 
correcting  software  deficiencies/simulation  problems,  and  performing 
Software  Quality  Assurance.  Trainer  Updates  supported  by  the  TSSA 
include  tactical  software  load  changes.  Engineering  Change  Proposals 
(ECPs),  Airframe  Changes  (AFCs),  Avionics  Changes  (AVCs),  Rapid 
Action  Minor  Engineering  Changes  (RAMECs),  Trainer  Engineering 
Change  Requests  (TECRs),  Discrepancy  Report  corrections  (contractor 
and  TSSA),  Minor  Fleet  Requests  (not  covered  by  TECRs),  and  minor 
software  changes  with  no  visible  trainer  impact. 

Conclusion:  The  TSSA  serves  a  very  valuable  function  and  derives 
synergy  from  its  collocation  with  the  aircraft  SSA.  A  “critical  mass”  of 
trainer  and  aircraft  experts  play  a  key  role  in  accomplishing  engineering 
changes.  This  capability  would  not  be  easily  duplicated.  Additional 
hardware  and  support  software  is  required  to  enhance  their  present 
capability.  TSSA  software  processes  have  not  been  subjected  to  an 
independent  assessment. 

H.  Subject:  Navy  F-14  Simulator  Change  Process  fGenerah  -  We  souoht 
to  outline  the  current  process  used  by  the  TSSA  to  perform  aircraft  related 
trainer  modifications. 

Results:  The  software  change  process  starts  when  the  F14  Software 
Change  Review  Board  identifies  a  Weapons  System  change  that  may 
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impact  the  trainers.  These  changes  are  forwarded  to  the  Trainer  Systems 
Change  Control  Board  and  the  Trainer  Advisory  Group  which  confirm  that 
the  trainer  change  is  required  or  desirable.  Changes  are  assigned 
priorities,  and  delegated  as  block  changes  or  assigned  to  the  TSSA  for 
more  immediate  response.  Once  changes  are  approved,  NAVAIR 
establishes  schedules  and  funding  for  project.  TSSA  then  develops  and 
integrates  the  changes  assigned  to  them  within  the  Trainer  Software 
Development  Facility  (TSDF),  and  tests  them  at  the  respective  trainer 
sites.  The  trainer  site  activities  are  usually  performed  on  2"*^  shift  to 
minimize  training  impact.  TSSA  verifies  and  validates  changes  at  the 
trainer  site  and  then  assists  with  Government  Final  Inspection. 

The  TSSA  handles  the  Configuration  Management  and  Data  Management 
functions  for  the  trainers.  The  CM/DM  group  within  the  TSDF  ensures 
that  each  Trainer  Software  Baseline  has  a  unique,  standard  ID  number, 
and  that  all  media  and  supporting  documentation  are  appropriately 
marked.  Changes  are  categorized,  reviewed,  and  implemented  under  CM 
oversight.  Current  and  past  software  baselines  of  each  trainer  are 
maintained,  and  a  trainer  change  history  is  documented. 

Software  documentation  is  controlled  by  the  TSSA.  Updates  to 
documentation  are  based  on  TSSA  software/hardware  changes. 
Documentation  support  includes  Acceptance  Test  Procedure  (ATP) 
generation,  Operation  &  Maintenance  (O&M)  manuals  changes, 
contractor  support,  and  information/data  support  to  other  Navy  activities 
as  required. 

The  TSSA  monitors  contractor  block  updates  to  the  F-14  trainers.  These 
activities  include  conducting  acceptance  test  procedures  to  validate 
trainer  changes,  providing  tactical  information  to  engineers,  providing 
configuration  management  and  data  management  of  trainer  software 
baselines,  monitoring  contract  compliance,  participation  in  Preliminary 
(PDR)  and  Critical  Design  Review  (CDR)  activities,  reviewing  software 
and  system  documentation,  performing  software  system  audits,  and 
evaluation  of  software  development  tools. 

Conclusion:  The  engineering  change  process  and  system  for 
implementation  encompasses  all  necessary  activities  and  functions.  They 
deal  with  all  types  of  proposed  changes  ranging  from  aircraft  ECPs  to 
field-generated  4720  modification  requests.  The  role  of  the  TSSA  is 
pivotal  from  management  and  execution  perspectives.  The  expertise  of 
the  TSSA  is  vital  in  describing  the  work  to  be  done  by  a  contractor, 
monitoring  progress  and  conducting  acceptance  tests.  Having  this  trainer 
experience  and  knowledge  of  the  aircraft  software  results  in  a  “smart 
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buyer”  capability. 

Subject:  Navy  F-14  Simulator  Change  Process  (Tactical  Tapes)  - 
Dual  sought  to  determine  the  current  process  used  by  the  TSSA  to 
accommodate  OFP  tactical  tape  change  to  simulators  and  the  impact  on 
schedule  and  budget. 

Results:  Dual  was  briefed  on  how  TSSA  schedules  are  determined  given 
the  size  and  complexity  levels  of  additional  trainer  capability  due  to 
tactical  tape  updates.  One  point  brought  up  was  the  misleading  nature  of 
the  term  “drop  in”  when  referring  to  the  tactical  tape  software  updates.  In 
fiscal  year  95,  the  D02  Tactical  Tape  update  resulted  in  the  addition  of 
over  4700  executable  software  lines  of  code  to  the  F-14D  trainer  host 
software  (see  Appendix  H  for  a  summary  of  D01  and  D02  code  changes). 
Although  these  trainers  use  many  of  the  actual  GFE  black  boxes  from  the 
aircraft;  a  sizable  amount  of  code  modules  exist  in  the  trainer  as  software 
simulations  (the  hybrid  approach).  These  simulated  modules  were 
designed  and  written  to  interface  with  the  trainer  host  computer,  and  do 
not  perform  the  identical  function  as  the  stimulated  boxes  they  emulate. 

Once  a  OFP  tape  is  released  from  the  WSSA  and  the  TSSA  has  modified 
the  appropriate  simulated  host  modules,  the  trainer  black  boxes  are 
loaded  with  the  new  tactical  data  with  a  WRA  (Weapon  Replaceable 
Assembly)  Load  Station.  See  Appendix  K  for  an  overview  of  this  device. 
This  device  consists  of  a  personal  computer  with  a  menu  driven  user 
interface  attached  to  a  Bernoulli  external  disk  drive.  The  accompanying 
interfaces  allow  attachment  of  the  F-14  mission  computer,  display 
processor,  converter  interface  unit,  and  airborne  radar  data  processor 
WRAs. 

Conclusion:  In  the  actual  aircraft  these  boxes  operate  together  because 
the  WSSA  engineers  have  designed  and  thoroughly  tested  each  box’s 
software  load,  and  assured  compatibility  between  each  unit  prior  to  use  in 
the  aircraft.  Once  this  tactical  tape  information  is  released  to  the  TSSA, 
the  unique  software  modules  used  in  the  trainer’s  “simulated  boxes”  must 
be  evaluated,  modified,  and  tested  to  ensure  they  will  correctly 
communicate  with  the  trainer’s  GFE  boxes.  Without  these  modifications, 
the  GFE  boxes  would  simply  ignore  the  simulated  black  box  software 
module’s  attempt  at  communication.  If  these  trainers  were  fully 
“stimulated”  devices,  then  the  tactical  tape  would  operate  without 
modification  of  host  software.  The  TSSA  personnel  have  a  working 
relationship  with  the  WSSA  engineers  ( whose  office  is  in  close  proximity 
to  the  TSSA),  and  this  facilitates  a  more  timely  update  of  the  host 
simulated  black  box  software. 
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J.  Subject:  Simulator  Change  Process  (Block  Upgrades)  -  We  sought  to 
determine  the  current  process  used  to  accommodate  Block  Upgrades  to 
simulators  and  the  ramifications  of  those  changes  to  schedule  and 
budget. 

Results:  For  the  Air  Force,  F-16  block  upgrades  are  performed  annually, 
while  the  Navy’s  F-14  block  upgrades  are  typically  on  an  18-24  month 
cycle.  Once  a  contractor  takes  a  baseline  out  of  government 
configuration  control,  two  baselines  for  the  same  device  exist,  with 
separate  teams  of  engineers  working  on  them.  The  contractor  is 
changing  and  upgrading  a  baseline,  and  the  TSSA  team  is  performing 
ongoing  changes  to  the  second  baseline.  Once  the  block  changes  are 
done,  the  new  baseline  is  returned  to  the  TSSA  where  a  large  amount  of 
effort  is  applied  to  retrofit  the  preceding  24  months  worth  of  TSSA 
changes  back  into  a  baseline  that  may  have  been  extensively  changed 
since  last  used  by  government  personnel. 

Conclusion:  Block  upgrades  present  a  special  challenge  to  the 
coordination  and  configuration  management  of  mass  trainer  updates.  The 
key  problem  here  is  that  block  changes  are  generally  accomplished 
external  to  the  TSSA  via  contract.  The  major  disconnect  occurs  when  a 
baseline  is  turned  over  to  a  contractor  and  is  out  of  the  jurisdiction  of  the 
TSSA  Configuration  Manager  for  a  relatively  long  period  of  time.  The 
existing  block  upgrade  process  requires  the  TSSA  engineers  to  provide  a 
baseline  of  software  and  documentation  to  the  contractor,  and  provide 
technical  assistance  and  related  activities  throughout  the  contract. 
Additionally,  as  with  the  ongoing  TSSA  efforts,  the  contractor  block  update 
process  requires  the  ability  to  access  baseline  software  quickly, 
modify/compile  host  software,  test  the  modifications,  and  document  the 
baseline  changes.  A  method  is  required  to  coordinate  and  oversee  both 
the  TSSA  and  contractor  development  activities. 

K.  Subject:  Navy  F-14  Trainer  Software  Development  Facility  fTSDF^ 
Capabilities  and  Requirements  -  To  determine  the  current  capabilities 
and  future  requirements  of  the  TSDF  in  order  to  continue  optimal  support 
of  TSSA  objectives. 

Results:  Dual  inspected  Trainer  Support  Development  Facility  (TSDF) 
located  at  the  TSSA.  This  lab  has  the  capability  to  support  code 
modification  and  compilation  of  source  code,  documentation,  database 
updates,  building  test  overlays,  partial  F-14D  cold  starts,  generation  of  site 
disks  and  tapes,  and  software  configuration  management.  Appendix  J 
outlines  equipment  upgrades  that  could  enhance  production.  Areas  of 
concern  by  TSDF  personnel  included  the  storage  capacity  of  the  F14D 
system,  the  development  environment,  automated  documentation 
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capabilities,  and  the  use  of  automated  software  configuration 
management  tools.  Appendix  J  went  on  to  explain  the  need  for  a 
computer  platform  to  support  off  line  development  in  a  UNIX  environment, 
the  ability  to  use  the  Microsoft  Access  database  program,  and 
implementation  of  a  software  configuration  management  tool.  Also 
discussed  was  the  need  to  store  and  move  data  from  the  TSSA  to  the 
trainer  sites,  as  well  as  provide  support  for  documentation  production  and 
review  efforts,  log  file  generation,  and  classified  data  handling. 

Conclusion:  Any  interface  unit  solution  proposed  should  operate  in 
concert  with  the  existing  equipment  and  procedures  currently  in  place 
within  the  TSDF.  Additionally,  it  must  be  flexible  in  order  to  accommodate 
new  devices  and  capabilities  envisioned  to  meet  future  needs  of  the  F-14 
trainer  community. 

V.  OBSERVATIONS  AND  RECOMMENDATIONS 

Once  the  literature  review,  data  collection,  discussions  with  designers,  users  and 
key  management  personnel  was  accomplished;  the  data  was  assessed  to 
determine  a  process  or  procedure  to  streamline  the  aircraft  to  trainer  upgrade 
process.  The  following  observations  constitute  the  areas  that  could  most  readily 
be  addressed  to  accomplish  the  goal. 

A.  Observation:  Existing  Configuration  Management  Practices  can  be 
improved. 

Discussion:  During  the  life  cycle  of  a  trainer,  all  information  concerning 
the  software,  hardware,  documentation,  courseware,  and  databases  is 
placed  into  a  configured  baseline,  which  is  then  administered  by  a 
Configuration  Management  support  element.  As  changes  are  identified 
and  implemented  to  the  baseline  data,  the  Configuration  Management 
(CM)  group  (which  usually  reports  to  program  management)  makes  sure 
that  items  to  be  changed  are  released  to  the  authorized  engineers,  all 
changes  are  properly  documented,  and  that  all  the  updated  and  properly 
tested  items  are  returned  to  CM  control  for  distribution  to  the  simulators. 

The  process  of  managing  changes  is  complicated  by  the  need  to  support 
a  team  of  TSSA  engineers  requiring  access  to  the  same  data  elements 
within  the  same  time  frame.  Change  regression  can  easily  occur  if  data  is 
not  carefully  managed  throughout  the  update,  testing  and  acceptance 
phases  of  the  upgrade  and  maintenance  process.  Throughout  this 
change  process,  the  CM  group  is  providing  test  loads  which  must  be  kept 
separate  from  the  configured  trainer  baseline.  This  is  to  ensure  that  no 
corrupted,  or  incorrect  software  is  allowed  onto  the  simulator  which  could 


15 


REV  A 


impact  training,  and  also  to  ensure  that  the  testing  efforts  are  addressing 
the  proper  problems.  Once  the  testing  process  has  confirmed  that  a  set 
of  authorized  changes  works  correctly  on  the  trainer,  the  modules  are 
moved  into  the  configured  baseline,  and  are  then  fonwarded  for  use  on  the 
individual  simulators. 

The  Configuration  Management  process  is  an  extremely  important 
function  of  the  TSSA.  The  management  of  change,  ability  to  monitor  and 
control  change  activity,  ability  to  archive  baseline  data,  the  collection  of 
metrics,  and  coordination  of  modules  across  multiple  baselines  and  trainer 
configurations  are  all  elements  of  cost  control  and  timeliness  of  the  update 
process. 

Recommendation:  The  present  system  of  Configuration  Management  is 
manual  in  nature.  By  implementing  a  computer  based  Configuration 
Management  Tool,  and  by  placing  baseline  data  for  all  devices  into  a 
central  computer  system  at  the  TSSA  many  benefits  could  be  derived. 
Refer  to  Appendix  K  for  representative  configuration  management  tools 
now  on  the  market.  These  tools  provide  control,  oversight  and 
management  reporting  capabilities  that  cannot  be  achieved  in  a  manual 
environment.  Information  such  as  which  engineer  is  currently  working  on 
a  module,  what  changes  were  made  to  a  module  (and  by  whom),  what 
versions  currently  exist,  what  differences  exist  between  versions,  what 
changes  were  made  across  configurations,  are  available  through  facility  of 
these  tools.  By  placing  the  CM  tool,  along  with  the  baseline  information 
into  a  central  computer,  data  is  obtained  by  engineers  in  a  controlled 
manner,  with  multiple  reporting  capabilities  available  to  assist  their  efforts. 

B.  Observation:  Existing  Block  Upgrade  Practices  are  inefficient  and 
cause  undesired  software  rework,  but  can  be  improved. 

Discussion:  Earlier  it  was  noted  that  a  separate  system  for  block 
upgrades  performed  by  contractors  is  currently  in  use.  While  it  has  been 
shown  that  changes  to  a  trainer  baseline  by  engineers  working  within  a 
particular  facility  can  be  effectively  managed  through  strict  protocols  and 
oversight  by  configuration  management,  the  complication  of  maintaining 
and  changing  separate  baselines  in  parallel  adds  substantial  costs.  Costs 
are  incurred  by  the  government  when  a  contractor  modified  baseline  is 
returned  to  the  TSSA.  The  new  contractor  baseline  must  first  go  through 
an  entire  acceptance  testing  process  on  the  target  system.  All  of  the 
TSSA  changes  applied  to  the  original  baseline  must  now  be  retrofit  to  the 
new  baseline.  Essentially,  each  individual  module  from  either  baseline 
that  was  changed  during  this  period  must  be  re-integrated  into  a  single 
baseline  to  be  maintained  by  the  TSSA. 
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Recommendation:  A  separate  baseline  for  contractor  block  upgrades 
should  be  terminated.  All  trainer  baseline  data  should  reside  within  the 
TSSA  Configuration  Manager’s  control/oversight  at  all  times.  Earlier  in 
this  section,  the  general  configuration  management  procedures  used  at 
the  TSSA  were  discussed.  Aside  from  the  fact  that  TSSA  and  contractor 
activities  are  often  located  in  different  locations,  the  procedures  used  are 
similar,  and  the  goals  identical.  A  central  on-line  repository  of  all  trainer 
data,  accessible  to  engineers  located  within  the  TSSA  or  in  remote 
locations  such  as  contractor  facilities,  WSSA  sites,  and  simulator 
installations  could  support  this  approach.  Using  an  automated 
configuration  management  tool,  the  TSSA  Configuration  Management 
department  could  extend  their  services  to  all  entities  working  with  the 
trainer  baselines. 

Another  way  to  consider  this  recommendation  is  to  make  note  of  how 
commercial  software  houses  maintain  control  over  their  assets.  Company 
engineers  are  often  located  in  different  cities,  or  different  buildings  within  a 
particular  area,  but  they  maintain  one  baseline  at  one  location  in  order  to 
maintain  consistency,  and  foster  reuse  of  existing  data  elements,  rather 
than  allowing  divergent  baselines  or  new  elements  to  be  created  for  one¬ 
time  use.  Also  consider  that  TSSA  control  of  all  baselines  should  lower 
contractor  charges  for  configuration  management  services,  and  allow 
government  to  more  closely  monitor  project  change  progress. 

C.  Observation:  The  transmission  of  secure  data  and  voice 

communications  between  Trainer  Development  Facilities.  Simulator 
and  Contractor  Sites  is  inadequate  and  will  be  even  more  important 
when  the  F-14  trainers  are  relocated 

Discussion:  The  change  process  requires  a  flow  of  information  between 
each  element  of  the  simulator  support  organization  to  occur  in  a  timely 
and  secure  manner.  The  WSSA  is  the  origin  point  for  Operational  Flight 
Program  data;  the  TSSA  Configuration  Manager  is  the  responsible  for 
trainer  baseline  data;  and  the  individual  engineer  creates  trainer  change 
information.  This  information  consists  of  computer  text,  such  as 
documents  and  software  code  structures,  voice  data  for  coordination  and 
consultation  use,  and  can  include  subjects  of  a  classified  nature.  Data 
movement  may  be  accomplished  locally,  or  sent  out  to  remote  locations 
such  as  a  simulator  site  or  contractor  facility. 

Recommendation:  A  method  be  provided  to  accommodate  the 
connectivity  between  each  operational  element  to  provide  data  and  voice 
communication  at  the  appropriate  level  of  security.  An  interface  unit 
allowing  connection  of  various  site  computers  both  internally  and 
externally  to  each  element  should  be  provided.  A  secure  voice 
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requirement  be  considered  for  communications  between  TSSA,  simulator 
site,  and  contractor  facilities  where  appropriate. 


D.  Observation:  The  present  method  of  testing  software  changes  at  the 
simulator  sites  is  marginal,  at  best,  but  will  be  inefficient  when  the  F- 
14  trainers  are  relocated. 

Discussion:  Currently,  no  trainer  is  collocated  with  the  TSSA,  therefore 
testing  must  be  accomplished  at  the  trainer  site.  Changes  are  initially 
made  using  the  TSDF  lab  computers.  These  are  then  hand  carried  to  the 
trainer  site  for  testing  and  checkout.  Since  the  simulators  are  in  use  for 
training  during  the  day,  checkout  of  new  loads  is  relegated  to  the  2""^  shift. 
The  time  available  must  be  shared  between  the  testing  of  fixes  on  the 
student  station  or  instructor  operator  station,  and  the  actual  programming, 
compiling  and  linking  with  the  host  computer.  This  situation  definitely 
limits  the  time  for  both  testing  and  programming  activities,  which  in  turn 
prolongs  travel  expenditures  and  impacts  the  routine  simulator 
maintenance  access  availability,  as  well  as  any  additional  unscheduled 
training  that  could  be  accommodated. 

Recommendation:  A  computer  workstation,  separate  from  the  simulator 
host  computer  be  provided  at  a  lead  remote  trainer  site  to  accommodate 
off-line  software  development  of  trainer  software.  This  workstation  should 
have  the  capability  of  hosting  a  UNIX  operating  system,  and 
accommodate  the  transfer  of  program  code  between  the  TSSA  baseline 
repository  database,  the  workstation,  and  the  host  computer  complex  in  a 
secure  manner. 

A  separate  workstation  could  accommodate  several  testing  methods. 

First,  it  would  allow  a  programmer  on  TAD  from  the  TSSA  to  perform 
software  development  off-line  while  the  simulator  was  being  used  for 
training  thereby  allowing  the  shift  to  concentrate  on  purely  on  testing 
activities  while  the  trainer  was  available.  Also,  the  TSSA  engineer  can 
remain  at  his  home  base  and  download  new  or  modified  modules  to  the 
remote  simulator  site  workstation.  Local  support  personnel  can  move 
these  modules  to  the  host  computer  for  final  compilation,  execution, 
linking,  and  testing,  and  report  back  findings  to  the  TSSA.  Local 
personnel  will  achieve  a  high  level  of  familiarity  with  trainer  software 
through  training  and  hands-on  experience. 

E.  Observation:  Trainer  “Hybrid”  Design  Approach  limits  ability  for 
“Drop  -  In”  Tactical  Tape  Capability. 

Discussion:  The  complicating  factor  behind  the  software  effort  involved 
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with  updating  and  maintaining  these  trainers  is  that  they  utilize  the  hybrid 
design  approach  (see  Appendix  D).  Although  the  F-14  trainers  may  have 
been  envisioned  to  have  “tape  drop  in  capability”,  in  actual  usage, 
ongoing  analysis  and  modification  to  trainer  host  software  is  required  in 
order  to  keep  the  trainer  in  pace  with  the  actual  aircraft  functionality. 

Recommendation:  In  order  to  have  a  true  “drop-in”  capability  a  new 
design  approach  would  be  required  for  each  trainer.  A  totally  stimulated 
approach  would  probably  be  required,  or  as  a  minimum,  all  simulated 
portions  of  the  trainer  would  require  extensive  rework  to  conform  to  an  as 
yet  unavailable  standard  interface  protocol,  addressing  both  aircraft 
hardware  and  simulator  needs.  This  protocol  would  have  to  be  developed 
with  co-use  of  OFP  code  by  aircraft  and  trainer  black  boxes  kept  in  the 
forefront.  No  open  ended  changes  on  either  the  aircraft  or  simulator  side 
could  be  accommodated.  Because  of  the  maturity  of  the  F-14  weapon 
system  and  trainers,  this  approach  is  not  recommended  due  to  anticipated 
costs  and  associated  risks  vs.  the  benefits. 

F.  Observation:  Having  TSSA  engineers  at  WSSA  facility  is  a 
necessary  coupling  in  the  update  process. 

Discussion:  To  provide  optimum  transfer  of  knowledge  concerning 
changes  to  aircraft  functionality,  the  hybrid  design  approach  requires 
coordination  between  the  OFP  programmers  at  the  WSSA  and  the 
simulator  support  programmers  at  the  TSSA.  The  OFP  data  is  developed 
at  the  WSSA  and  is  coordinated  with  the  TSSA  engineers  who  conduct 
the  analysis  for  impact  to  the  simulated  portions  of  the  trainer.  New  or 
modified  host  modules  are  produced,  compiled  and  tested  for  proper 
operation  on  the  target  devices  (in  so  far  as  possible  without  the 
availability  of  a  trainer  test  bed).  The  process  outlined  above  requires  a 
group  of  engineers,  intimately  familiar  with  the  target  trainers  technical 
operation,  to  be  in  close  contact  with  the  aircraft  software  development 
activity. 

Recommendation:  The  technical  coordination  that  currently  exists 
between  the  F-14  WSSA  and  the  TSSA  be  preserved.  In  the  event  that  a 
full  TSSA  staff  is  no  longer  collocated  with  the  WSSA,  then  a  smaller 
group  of  simulation  engineers  should  remain  to  represent  the  TSSA 
interest  in  the  aircraft  upgrade  activities.  An  interface  unit  augments  the 
flow  of  information  between  the  WSSA  and  TSSA  engineering  staff.  The 
TSSA  should  set  a  goal  for  achieving  a  level  III  software  capability  within 
two  years. 
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VI.  RECOMMENDED  SYSTEM  DESIGN 

The  primary  goal  of  the  engineering  change  support  system  is  to  support  the 
efforts  of  the  TSSA  team  and  the  contractors  that  perform  the  block  upgrades. 
The  system  supports  the  creation,  control,  and  distribution  of  trainer  baseline 
information  to  include  software  modules,  OFP  data,  databases,  hardware 
documentation,  and  manuals.  The  system  facilitates  the  capture,  control, 
storage  and  configuration  management  of  all  data  associated  with  the  training 
devices.  It  allows  movement  of  data  between  existing  host  computer  complexes, 
and  allows  for  attachment  of  other  devices  such  as  personal  computers,  external 
storage,  and  support  equipment  such  as  the  WRA  Load  Station,  (see  Appendix 
I)  which  is  used  to  load  OFP  tape  into  the  trainer  black  boxes.  The  individual 
units  of  the  system  attach  to  local  area  networks  (LAN)  and  wide  area  networks 
(WAN)  such  that  data  flow  within  and  between  each  TSSA,  WSSA,  contractor 
facility,  or  trainer  site  can  be  readily  accomplished.  Due  to  the  security 
classification  of  these  trainers,  the  ability  to  transmit  STU  III  protocol  for  both 
voice  and  data  is  provided. 

Figure  VI-1  depicts  the  system  designed  to  be  responsive  to  fleet  needs  and  that 
takes  advantage  of  the  capabilities  of  the  various  organizations  involved  in  the 
trainer  update  process. 

The  Interface  Unit  design  approach  features  computers  and  peripheral  devices 
that  can  be  customized  according  to  facility  need.  In  the  case  of  a  TSSA  where 
the  central  baseline  and  development  efforts  are  accomplished  by  groups  of 
engineers,  a  network  server  computer  is  appropriate  for  a  multi-user  role.  The 
Primary  Interface  Unit  (Figure  VI-2)  is  designed  to  meet  this  requirement.  In  a 
setting  where  a  computer  would  be  used  less  frequently  such  as  at  a  simulator 
site,  a  Remote  Interface  Unit  (Figure  VI-3)  featuring  a  single  workstation,  smaller 
storage  capacity,  and  fewer  peripherals  are  provided.  Peripheral  devices  such 
as  internal  and  external  disk  drives,  floppy  drives,  digital  audio  tape  drives,  CD 
ROM  drives,  various  printers,  and  the  like  are  customized  within  each  unit 
according  to  each  site’s  individual  requirements.  The  TSSA  Primary  Interface 
Unit  features  all  of  these  devices  to  accommodate  any  data  transfer  demands  of 
the  simulators. 

A  typical  installation  of  a  complete  Interface  Unit  System  consists  of  placing  a 
Primary  Interface  Unit  at  the  TSSA,  with  a  Remote  Interface  Unit  at  each 
simulator  site.  As  additional  facilities  require  access  to  the  TSSA  data  by 
contractors  and  other  government  agencies  involved  with  trainer  design  and 
management  activities,  additional  Interface  Units  are  added  to  the  system. 
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FIGURE  VI- 1  (2  of  2) 


INTERFACE  UNIT 


REV  A 


23 


TSSA  PRIMARY  INT01FACE  UNIT 
BLOCK  DIAGRAM 


TRAINER  SITE  REMOTE  INTERFACE  UNIT 
BLOCK  DIAGRAM 


REV  A 


A  Primary  Interface  Unit  is  intended  to  service  the  Training  System  Design 
Facility,  and  the  TSSA  Configuration  Management  department.  For  the  TSDF  it 
can  function  as  a  UNIX  development  platform  to  allow  software  development  and 
script  file  generation  independent  of  the  current  lab  equipment.  If  desired,  the 
unit  can  function  as  network  server  to  accommodate  multiple  users  of  the  unit 
throughout  the  local  facility.  This  feature  allows  the  linking  of  the  TSSA 
engineers  to  the  WSSA  on  a  common  net  (if  collocated).  Data  is  transferred 
between  the  existing  development  computers  in  the  TSDF  lab  through  the  RS- 
232  links  provided.  The  CM  department  implements  the  configuration 
management  software  tool  on  the  unit,  as  well  as  using  it  to  store  and  backup  all 
trainer  data  on  its  expanded  disk  drive.  For  the  rapid  and  secure  movement  of 
data  between  the  TSSA,  contractor  or  simulator  sites,  a  STU  III  modem  is 
provided  on  each  unit  which  can  transmit  encrypted  data  or  open  data  via  plain 
old  telephone  system  (POTS).  As  a  future  feature,  a  DIS  ++/HLA  Interface  Unit 
is  also  available  on  the  interface  unit  as  desired. 

The  Remote  Interface  Unit  is  intended  to  be  placed  at  simulator  sites,  a 
TSSA/WSSA  outpost,  or  at  contractor  or  government  facilities.  The  unit  allows 
the  secure  movement  of  data  between  the  TSSA  and  the  various  user  sites. 
Within  the  simulator  facility  the  unit  permits  the  download  of  modules  and  load 
packages  into  the  simulator  host  computers,  or  the  WRA  Load  Station  for 
movement  of  OFP  data  to  the  trainer  black  boxes.  A  UNIX  operating 
environment  is  provided  on  the  Interface  Unit  computer  so  that  software 
development  can  be  supported  during  periods  when  the  host  computer  is  being 
used  for  simulation  purposes.  This  allows  trainer  off  hours  to  be  devoted  to 
testing  and  evaluation  of  new  software,  rather  than  having  to  share  limited 
computer  resources. 

VII.  ESTIMATES  OF  TECHNICAL  FEASIBILITY 

The  System  Concept  for  Networking  Interface  Units  is  low  technical  risk.  All 
components  are  commercial  off  the  shelf  units,  readily  available  from  a  variety  of 
manufacturers.  Refer  to  sample  data  sheets  on  the  computers  (Appendix  L), 
and  configuration  management  software  packages  (Appendix  K)  that  have  been 
examined  in  this  investigation.  This  equipment  is  very  straightforward  with  the 
flexibility  to  accommodate  modifications,  additions  and  upgrades  in  the  future. 

The  NDI  hardware  required  to  implement  this  project  is  available  from  several 
companies  including  Sun  Microsystems,  Hewlett  Packard,  IBM,  and  Compaq 
Computers.  Interface  and  networking  connectivity  for  the  net-servers  and 
workstations  include  industry  standards  such  as  token  ring,  high-speed  serial 
interface,  ISDN,  FDDI,  and  SCSI.  This  will  allow  ready  interface  to  site 
equipment  and  connectivity  to  existing  networks.  Operating  systems  include 
UNIX  based  systems,  with  languages  such  as  C,  C++,  and  FORTRAN.  All  units 
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will  support  optional  peripheral  devices  such  as  Digital  Audio  Tape  backup 
drives,  external  hard-drives  CD-ROM  drives,  printers,  floppy  drives  etc.  Several 
Configuration  Management  software  tools  have  also  been  identified  that  would 
meet  requirements  of  the  TSSA. 

VIII.  VALUE  OF  THE  PROJECT  TO  THE  NAVY  AND  DEPARTMENT  OF  DEFENSE 

There  are  essentially  two  dimensions  of  value  with  this  project. 

First,  the  ability  to  maintain  training  devices  current  with  the  parent  weapon 
system  results  in  more  effective  training.  Because  operational  readiness  is  a 
function  of  how  well  aircrews  are  trained,  it  is  imperative  that  training  assets, 
such  as  flight  simulators,  provide  the  most  effective  training  possible.  With  an 
initial  investment  in  simulators  totaling  millions  of  dollars,  any  degradation  of 
capability  is  unacceptable.  Differences  in  the  functional  performance  of  the 
simulator  must  be  minimized  to  ensure  that  training  transfer  takes  place. 

Secondly,  the  system  for  updating  simulators  can  be  improved  to  increase 
efficiency  and  reduce  overall  costs.  Through  the  application  of  good  systems 
engineering  principles  and  the  use  of  current  technology,  efficiencies  in  the 
fundamental  process  can  be  realized.  Computer  software  support  is  human 
resource  intensive,  which  is  costly  to  the  government.  An  improved  system  that 
avoids  parallel,  uncontrolled  development,  applies  human  labor  and 
management  most  effectively  and  facilitates  data  and  information  transfer  will 
result  in  a  considerable  savings  to  the  government. 

The  Navy,  specifically  the  Naval  Air  Systems  Command  is  the  immediate 
beneficiary  of  the  improved  system,  however,  the  concept  has  widespread 
application  throughout  the  Department  of  Defense  in  support  of  all  warfare  and 
platform  software-intensive  simulators.  Given  that  the  annual  expenditure  of 
DOD  training  devices  is  well  in  excess  of  $1.5  Billion  dollars,  the  potential 
savings  due  to  improved  software  support  for  the  growing  inventory  becomes 
very  significant. 

IX.  COMMERCIALIZATION 

Dual’s  management  is  committed  to  transitioning  this  R&D  effort  to  a  product  line 
and  related  services  during  the  commercialization  phase,  i.e.  Phase  II  and  Phase 
III  of  the  SBIR  Program.  The  commercialization  plan  begins  with  the  installation 
of  the  first  system  to  support  the  F-14  training  system  program.  Dual  is 
recognized  within  and  outside  of  the  simulation  and  training  community  as  a 
provider  of  quality  products  and  services.  Our  experience  and  technical  “know¬ 
how  lend  credibility  to  marketing  an  improved  process  for  support  of  large  scale 
software  systems. 
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Following  the  installation  of  the  system  to  support  the  F-14  community,  other 
aviation  platforms  will  benefit  from  similar  installations.  Beyond  aviation 
platforms  within  the  Navy  are  training  simulators  for  surface,  submarine  and  land 
warfare.  Our  plan  is  to  make  the  demonstrated  system  available  to  the  Navy,  Air 
Force,  Marines,  Army  and  Coast  Guard. 

The  spin-off  possibilities  to  the  private  and  public  sectors  are  numerous.  Dual 
will  market  this  approach  to  the  commercial  airlines,  NASA  and  the  FAA.  In 
addition,  companies  engaged  in  large-scale  software  development,  especially 
where  development  occurs  at  multiple  and  distributed  locations,  will  be  interested 
in  improving  productivity  and  reducing  costs. 

Dual  has  experience  in  commercializing  products.  We  are  currently  marketing  a 
family  of  security  access  systems  throughout  North  America.  Dual  is  a  charter 
member  of  the  Training  and  Simulation  Technology  Consortium  (TSTC)  which  is 
funded  through  the  Technology  Reinvestment  Project  (TRP).  It’s  mission  is  to 
assist  defense  contractors  in  finding  new  markets  for  military  products,  services 
and  technologies.  We  intend  to  use  TSTC  to  assist  us  in  the  marketing,  sales 
and  distribution  of  commercial  applications  of  the  software  support  system. 

X.  JUSTIFICATION  AND  PLANS  FOR  PHASE  II  CONTINUATION 

The  immediate  impetus  for  installing  the  software  support  system  for  the  F-14 
program  is  the  relocation  of  the  aircraft  and  training  devices  to  NAS  Oceana,  VA. 
An  improved  means  for  upgrading  the  trainers  is  a  result  of  OFP  and  other 
engineering  changes  is  vital  to  maintaining  operational  readiness.  An  initial 
investment  will  result  in  a  considerable  savings  in  fleet  support  dollars  and 
improved  training  of  our  aircrews. 

Dual’s  experience  in  building  complex  simulators,  re-hosting  fielded  devices  and 
modifying  trainers  lends  us  exceptionally  qualified  to  install  and  operate  the  F-14 
software  support  system.  By  working  closely  with  the  WSSA,  TSSA,  MFS,  and 
the  NAWCTSD  ISEO,  Dual  will  develop  a  system  that  meets  user  and  developer 
needs.  It  is  imperative  that  all  parties  have  some  ownership  in  the  process  and 
the  “division  of  labor”  in  implementing  this  improved  system. 

Dual’s  plan  for  Phase  II  is  to  develop  functional  requirements  and  specifications 
for  the  hardware,  software  and  other  components  of  the  interface  system  and 
install  the  system.  Detailed  cost  estimates  will  be  developed  as  rough  orders  of 
magnitude  in  the  Phase  II  proposal  and  refined  within  30  days  after  the  Phase  II 
contract  award.  A  project  team  will  be  assembled  to  include  the  players 
identified  earlier,  managed  by  NAVAIR.  As  an  integrated  team  initiative, 
milestones  will  be  finalized,  the  initial  system  designed,  developed  and  installed 
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by  Dual.  It  is  envisioned  that  Phase  II  will  take  approximately  18  months  to 
execute.  A  budgetary  estimate  will  be  provided  in  the  Phase  II  proposal. 
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F-14  AIRCREW 
SIMULATOR 
DEPLOYMENT 


SIMULATOR 

TYPE 

RFT 

REMARKS 

NAS  OCEANA 

2F95A  (#4) 

F-14AOFT 

DEC  97 

Upgrade  visual ,  block  upgrade,  computer 

2F95A  (#3) 

F-14AOFT 

MAR  98 

suite  upgrade  at  Patuxent  River. 

Upgrade  visual ,  block  upgrade,  computer 

15C9A(#2) 

F-14AMT 

JUN  97 

suite  upgrade  at  Patuxent  River. 

Simtec  upgrade/rehost. 

15C9A(#3) 

F-14A  MT 

AUG  97 

Simtec  upgrade/rehost. 

2F169  (2  of 

F-14B  OFT 

FY  97 

Consists  of  two  separate  dome  simulators 

them) 

2F153 

F-14D  MFT 

ON  LINE 

with  ability  to  be  linked  together. 

2F154 

F-14D  WST 

AUG  97 

Dual  dome  WST. 

NAS  FT.  WORTH 

2F95  (#1) 

F-14AOFT 

ON  LINE 

Original  unmodified. 

15C9A(#1) 

F-14AMT 

OCT  97 

ATSUGI,  JAPAN 

2F95  (#2) 


F-14A0FT 


JUL97 


No  motion  base. 
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AH-1W  TRAINER  QUESTIONS 


MEMORANDUM 


TO: 


Clark  L.  Morris,  Dual  Incoiporated,  Navy  SBIR  Project 


FROM 


Mike  Sakach,  MFS 


SUBJECT: 


Reply  to  questions  about  AH- 1  Training  Device  software  update  methods 


DATE: 


30  SEP  96 


1.)  Before  answering  the  questions  outlined  in  your  fax,  1  would  like  to  make  a  few 
clarifications  to  statements  that  I  read  in  the  August  SBIR  inoatfaiy  progress  report. 

a.)  The  Manned  Flight  Simulator  (MFS)  facility  at  NAWC  AD,  Patuxent  River  has  been 
tasked  by  NAVAIR  PMA  2052L  to  build  three  AH-IW  Aircrew  Procedure  Trainers  (APT), 
The  first  device  was  delivered  to  Camp  Pendleton  in  September  1995.  The  second  device 
will  be  delivered  in  November  1996  to  the  Marine  Reserves  in  Atlanta.  Tlie  third  device 
will  be  delivered  to  the  Marine  Reserves  in  New  Orleans  during  the  second  quarter  of 
1997. 


b.)  The  AH-IW  Weapon  System  Software  Activity  (WSSA)  is  located  at  NAWC  WD, 
China  Lake.  The  Trainer  Software  Support  Activity  (TSSA)  for  the  APTs  is  located  at 
Camp  Pendleton. 

c).  MFS  has  not  transferred  software  updates  via  modem  to  the  APT  at  Camp  Pendleton. 

has  connected  to  the  APT  simulation  computers  at  Camp  Pendleton  via  modem  and 
then  edited,  compiled,  and  linked  files  to  create  a  new  version  of  the  simulation  executable 
code. 


2.)  The  answers  to  your  questions: 

a. )  How  often  do  you  receive  mission  computer  updates  (or  aircraft  block 
changes)  for  incorporation  into  your  AH-1  trainer? 

APT  1  has  five  aircraft  black  boxes  that  contain  code.  The  black  boxes  were  procured  by 
MFS  with  the  (at  that  time)  current  versions  of  software  and  delivered  with  the  device 
without  modification.  APT  2  has  eight  black  boxes  that  contain  code,  five  of  which  have 
been  loaded  with  newer  versions  of  software.  Once  the  devices  are  delivered,  they  are 
maintained  by  the  TSSA. 

b. )  Can  you  give  typical  examples  of  what  these  changes  consist  of?  Arc 
they  mainly  software  updates^  or  are  other  changes  involved,  such  as 
hardware  installations  or  modifications? 

So  far  the  changes  have  consisted  of  software  only. 

c. )  Physically,  what  do  you  get  from  the  Aircraft  Software  Support 
activity?  A  tape,  disk,  or  document  describing  the  changes?  What  are  the 
size  of  typical  software  changes? 

We  send  the  black  boxes  to  the  WSSA  at  China  Lake  who  loads  the  new  software  and 
returns  them  to  us.  We  do  not  have  any  information  regarding  the  scope  or  size  of  change. 


d. )  When  you  get  this  data,  what  language  is  it  in;  and  do  you  get  a  source 
code  listing  for  it? 

We  do  not  get  a  code  listing  and  or  even  know  what  language  it  is  in.  We  have  the 
interface  design  documents  (ICD)  for  each  black  box. 

e. )  How  do  you  get  the  data  from  the  Aircraft  Software  Support  Activity? 
Does  it  come  by  mail  or  over  a  modem  or  other  data  medium? 

The  only  data  we  have  received  are  the  ICD’s  which  came  by  mail. 


f. )  What  are  the  security  considerations  for  this  Data  as  it  travels  to  your 
facility,  and  once  you  receive  it? 

The  black  boxes  and  their  ICD’s  are  unclassified. 

g. )  Once  you  get  this  data  to  your  AH*1  TSSA,  who  is  it’s  custodian,  and 
how  is  it  stor^? 

N/A 

h. )  What  process  do  you  use  to  make  Aircraft  Operational  Flight  Program 
data  useable  by  your  training  devices?  Is  this  data  suitable  for  direct  load 
to  the  trainer’s  Mission  Computer  (or  equivalent),  or  do  your  engineers 
have  to  modify  it? 

We  use  the  code  “as  is”. 

i. )  If  your  engineers  have  to  modify  the  OFP  data  prior  to  loading  on  your 
trainers,  do  they  follow  pre*arranged  standardized  steps,  or  do  they  have  to 
perform  an  analysis  and  customize  the  code  each  time? 

N/A 

j)  How  do  you  transfer  the  OFP  data  (unmodified  or  modified)  from  your 
AH-1  TSSA  to  each  individual  trainer  computer  (or  mission  computer). 

Can  you  describe  the  process,  equipment,  and  personnel  involved?  Can 
you  supply  a  block  diagram  or  other  info  on  your  current  setup? 

N/A 

k.)  Do  you  find  your  current  system  for  performing  OFP  uploads  adequate? 
If  you  were  to  improve  this  system,  would  yon  place  an  emphasis  on  speed 
of  data  transfer,  or  security,  or  cost  of  equipment  to  move  the  data?  how 
much  human  interaction  would  you  expect  to  see  during  the  operation  of  a 
system  such  as  yours? 


N/A 
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TRAINER  DESIGN  APPROACHS 


TRAINER  DESIGN  APPROACHES  -  Training  devices  utilize  one  of  three  basic 
methods  to  operate:  these  are  the  “simulation” ,  “stimulation”,  and  “hybrid”  design 
approaches. 

The  “Simulation”  method  utilizes  software  code  modules  within  the  host 
computer(s)  to  replicate  the  functions  of  the  OFP  driven  “black  boxes”  that  are 
found  in  modern  aircraft.  No  actual  black  boxes  exist  on  the  training  devices. 

The  advantage  to  this  approach  is  that  the  trainer  is  not  dependent  on  actual 
aircraft  hardware,  which  can  be  very  expensive  or  not  available  during  the  trainer 
build  cycle.  The  disadvantage  of  this  design  approach  is  that  it  requires  close 
coordination  in  the  initial  design  effort,  between  the  aircraft  system  and  training 
device  software  engineers,  to  include  provisions  for  OFP  updates.  Unless  this 
design  goal  was  accomplished,  when  modifications  are  made  to  the  OFP  data, 
the  trainer  software  will  have  to  be  modified  for  each  individual  operational 
change  of  the  aircraft.  These  types  of  changes  are  usually  expensive  and  time 
consuming,  and  often  do  not  yield  the  desired  results. 

The  “Stimulation”  method  uses  the  host  computer  to  provide  appropriate  inputs 
to  the  actual  OFP  operated  aircraft  hardware.  The  host  computers  task  is  to 
provide  “believable”  data  to  the  aircraft  hardware  to  cause  it  to  respond  as  if  it 
where  in  the  desired  flight  regime.  The  advantage  to  this  approach  is  that  as 
changes  are  made  to  the  OFP,  the  latest  data  can  be  uploaded  and  run  with 
limited  modifications  to  the  host  software  load.  The  cost  of  host  software 
maintenance  is  lower  on  a  fully  stimulated  trainer  than  either  the  simulated  or 
hybrid  approaches.  A  potential  drawback  to  this  design  approach  is  that  the 
OFP  hardware  was  originally  intended  for  in-flight  use  and  older  equipment  is  not 
set  up  to  handle  the  demands  of  training  devices  such  as  freeze,  reset,  and 
playback.  Newer  on  board  computers  program  designs  are  including  “hooks”  for 
simulator  use,  and  some  are  being  retrofit  for  this  purpose.  The  drawback  to 
using  actual  aircraft  hardware  in  trainers  is  generally  cost,  availability  of 
replacement  components,  and  the  OFP  change  issue. 

The  “Hybrid”  method  utilizes  elements  from  both  the  “Simulation”  and 
“Stimulation”  design  approaches.  Key  pieces  of  the  trainer  design  are  stimulated 
aircraft  equipment,  while  others  aircraft  functions  are  replicated  strictly  by 
software  modules  on  the  host  or  other  non-aircraft  equipment.  From  a 
designer’s  viewpoint,  this  approach  gives  the  leeway  to  utilize  hardware  and 
software  components  according  to  availability,  cost,  maturity  of  design,  and  how 
each  can  meet  the  demand  of  the  product  specification.  The  advantage  is  that 
the  level  of  support  for  OFP  changes  can  be  mitigated  somewhat  compared  to 
the  full  simulation  approach,  but  of  course  host  software  will  require  changes  and 
OFP  data  may  require  tailoring  for  trainer  use. 
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F-15  A/B  AIRCREW  TRAINING  DEVICES  (ATD) 
OPERATIONAL/ SUPPORT  CONFIGURATION 
MAIIAGEMENT  PROCEDURE  (0/S  CMP) 


1.0  INTRODUCTION 


1.1  EuQose,  This  Operational / Support  Configuration  Management 
Procedure  (0/S  CMP)  details  the  concepts  and  procedures  used  for 
OO-ALC/MMA  management  and  configuration  control  of  F-16  A/B  Aircrew 
Training  Devices  (ATD)  in  support  of  the  United  States  Tactical  Air 
Forces  (TAF),  and  European  Participating  Air  Forces  (EPAF). 

1.2  Scope..  The  United  States  Tactical  Air  Forces  (TAF),  and  the 
European  Air  Forces  of  Belgium,  Denmark,  The  Netherlands  and  Norway 
are  the  Using  Commands  being  supported  through  this  0/S  CMP. 


1.2.1  F-16  Aircrew  Training  Devices  (ATD):  This  document  provides 

basic  management  and  configuration  control  procedures/pol icies 
pertaining  to  computer  resources  support  for  the  F-16  A/B  ATD  which 
consists  basically  of  the  Weapon  System  Trainer  (WST)  and  Visual 
System.  The  F-16  WST  includes  the  Operational  Flight  Trainer  (OPT), 
Electronics  Warfare  Training  Device  (EWTD),  Norwegian  EWTD  (NEWTD), 
and  Digital  Radar  Landmass  System  (DRLMS).  _ _ 

/H>^ 

1*2. 2.1  All  USAF  F-16  A/B  WST  devices  will  be  supported  under  Tix: ^ 

Contract  Logistics  Support  (CLS)  policy  managed  by  00-ALC/LIRBE .  This 
policy  includes  software  support  through  the  F-16  Training  Svstem 
Support  Center  (TSSC). 


1.2.2  Trainer  Support  Policy: 


1.2. 2. 2  EPAF  F-16  A/B  WST  devices  are  not  under  CLS  support  policy, 
but  will  be  supported  through  Service  Contracts  managed  by 
00-ALC/LIRBE.  aPAF  WST  devices  will  also  receive  software  support 
through  the  TSSC. 


1.2. 2. 3  Non-WST  type  training  systems  (Simulated  Aircraft  Maintenance 
Trainers  -  SAMTS ,  Hardware  Aircraft  Maintenance  Trainers  -  HAMTS, 
etc.)  will  be  addressed  under  a  separate  0/S  CMP. 


1.2.2. 4  Funding  for  CLS/TSSC  contracts  and  applicable  updates  or 

modifications  produced  by  the  TSSC  contractor  will  be  cost-  _ 

shared  up  front  by  all  Users  on  a  trainer  population  ratio  basis  per 
Addendum  C. 


1.2.3  Maintenance  Concepts:  Basic  procedures  outlined  herein  shall 
be  used  to  manage  and  control  all  changes  to  F-16  WST  software  and/or 
hardware  baselines  resulting  directly  or  indirectly  from  weapon  system 
concurrency  requirements,  deficiency  correction,  operational 
enhancements  or  redirection  of  trainer  utilization  requirements. 
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1.2.4  User  Compliance:  All  Air  Force  activities  involved  in  the 
change  process  shall  ensure  that  these  procedures  are  rol lowed,  and 
that  the  associated  intra-command  controls  and  procedures  allow  for 
their  compliance. 
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1.2.5  0/S  CMP  Maintenance:  As  a  living  document,  this  0/S  CM?  will  be' 

updated  periodlcailyto  Te fleet  requirements  of  the  latest  coniig- 
urations  as  determined  by  the  Training  devices  Multinational  Computer 
Resources  Working  Group  '(TDMCRWQ) .  It  will  be  upgraded  to  the 
Computer  Rewources  Life  Cycle  Management  Plan  (CRLCMP)  following  the 
next  major  system  upgrade  I  AW  APR  800-  14  ahd  AFLCR  800-21. 

i . 3  Ado 1 i cab i 1 1 ty . 

1.3.1  General:  The  procedures  described  hferein  apply  to  ail  Tac*!cai 
Air  Force  (TAP)  users,  the  European  Participating  Air  Forces  'E?AF:-:'. 
and  to  the  F-lb  ATT  support  organizations  within  TAP,  APLC  and  AF£C. 
This  document  is  based  on  requirements  and  guidance  outlined  in 
Section  6.1  of  this  0/S  CMP  plus  the  following: 

a.  The  F-16  A/ c  WST  Multinational  Computer  Resources  Integrated 
Support  Plans  (CRISP». 

b.  F-iG  A/B  Memorandum  of  Under s tand i ng  (M0U»  Between  the 
Government  of  the  United  States  and  the  Governments  cf  Belgium. 

Denmark,  the  Mether lands  and  Norway  (6  June,  1976)  . 

c .  F -  1 c  A/B  WS T  User’s  Group  Charter,  25  June  19 SG . 

1.3.2  F-16  WST  System  Description: 

\ 

1.3.2.  I  OFT  (Operational  Flight  Trainer): 

a.  Computation  System:  The  F-16  A/B  OFT  is  controlled  and  driven 

by  a  ND- 100/500  computer  complex.  The  computer  system  controls  ail 
required  interlacing  to  the  Signal  Conversion  Equipment  ( SCE )  / cockp 1 1 
controls  and  indicators.  Avionics  Multiplex  Bus  (AMUX) ,  Visual 
Instruct lonal  System.  DRLMS  and  EWTD/NEWTD  to  control  the  simulation. 
The  Computer  Program  System  (CPS)  is  programmed  in  FORTRAN  with  the 
exception  ol  a  few  modules  coded  in  and  Assembly. 

NOTE:  At  the  next  major  software  upgrade,  the  redesign 

or  aadition  of  more  than  one- third  of  the  software 
for  the  system  or  subsystem,  requires  the  use  o  f 
ADA  software  language.  This  includes  major  block 
updates  to  systems  both  before  and  after  program 
management  r espons i b 1 1 i ty  transfer  occurs.  Analysis 
and  risk  management  approaches  as  described  in 
current  risk  analysis,  must  be  used  to  quantify 
the  scope  and  effect  of  the  change  to  determine 
if  the  software  should  be  rewritten  entirely  in 
ADA,*  the  language  should  be  mixed  or  the  modifi¬ 
cation  should  be  done  in  the  original  language. 

See  AF/CVA  p»oilcy  letter,  9  Mov  SQ  ,  and  subsequent 
policy  letter?  and  regulations  for  additional 
guidance  and  waiver  approval. 

b.  Cockpit:  The  simulator  cockpit  is  a  replica  of  the  F-16 
aircraft  cockpit  depending  on  conf Igurat ion .  All  instruments, 
FlyBy^Wire  controls,  avionics  displays,  and  indicators  are  identical 
in  appearance,  color,  feel  and  function  to  those  of  the  F-16  aircraft 
design  being  simulated.  A  mechanoreceptor  cueing  system  comprised  oi 
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a  G-seat.  .  Anti-G  suit  and  Seat  Shaker  is  integrated  into  the  cockpit 
to  help  simulate  the  sensations  of  motion.  An  aural  cue  system 
reproduces  realistic  aircraft  sounds. 

G.  Avionics  System:  The  Fire  Control  Computer  (XFCC) ,  Stores 
Control  Panel  (SCP),  Central  Interface  Unit  (XCIU) ,  Data  Transfer  Unit 
(DTU) ,  Heads-Up  Display  (HUD) ,  Fire  Control  Navigation  Panel  (FCNP) 
and  Hadar  Electro-Optics  (REO)  are  unmodified  aircraft  hardware.  Other 
devices  connected  to  the  Avionics  MUX  Bus  such  as  the  Combined 
Altitude  Radar  Altimeter  (CARA),  Fire  Control  Radar  (FCR) .  Inertial 
Navigation  System  (INS) ,  and  Central  Air  Data  Computer  (CADC) .  are 
simulated  In  software  and  connected  to  the  MUX  bus  via  a  Programmable 
Terminal  Controller  (PTC). 

d.  Instruct ional  System:  The  Instructor  Operator  Station  (lOS)  is 
comprised  of  three  Silicon  Graphics  Workstations  with  an  Ethernet 
interface  to  the  NORD  100.  The  lOS  provides  interactive  color 
displays,  using  touch  screen  technology,  and  a  cockpit  instrument 
repeater  pane  1 . 

1.3. 2. 2  Electronic  Warfare  Training  Device  (EWTD)  and  Norwegian  EWTD 
(NEWTD) :  The  EVTD  consists  of  a  ND-10  computer  system,  10  Megabyte 

disk  drive,  a  Terminal  and  EW  electronics  cabinet.  The  NEWTD 
consists  of  a  Nord  10/^^ computer  system.  75  Megabyte  disk  drive  and 
EW  electronics  cabinet.  Additionally,  Norway  (NEWTD)  also  uses  an 
unmodified  (0M-47^7T"ALR-69  Digital  Processor  stimulated  by  video  signals 
generated  b^^the  EW  cabinet. 

1.3. 2. 2.1  Panels/displays  are  installed  in  the  OFT  cockpit  and 
repeated  on  the  lOS.  Interface  to  the  OFT  is  via  a  universal  DMA 
channel . 

1.3. 2. 2. 2  An  extensive  CPS  la  provided  for  real-time  simulation  and 
computer-aided  update  capability  consisting  of  eleven  major  functions. 
These  functions  Include  EWTD  Control,  Radar  Warning  Receiver  (RWR) 
Equipment.  Electronic  Counter  Measures  (ECM)  Equipment;  JARM  (Jammers, 
Artillery,  Radar . Miss i 1 es )  environment.  Interface  Control,  ECM 
Equipment  Support,  RWR  Equipment  Support.  JARM  Environment  Support, 
Support  Utilities,  Diagnostics,  and  Encounter  Support, 

1.3. 2. 2. 3  The  CPS  is  programmed  in  FORTRAN  with  the  exception  of 
certain  modules  which  require  the  efficiency  and  flexibility  of 
assembly  level  code. 

1.3..2.3  DRLMS  (Digital  Radar  Landmass  System)  :  The  DRLMS  provides  a 
simulation  of  the  air-to-ground  modes  and  displays  of  the  F-16 
AN/APQ-66  Fire  Control  Radar.  The  system  consists  of  a  Norsk  Data 
ND- 10/50  computer  system,  one  75  megabyte  disk  drive,  two  288  megabyte 
disk  drives,  an  Update  Console  Subsystem,  a  Radar  Simulation 
Subsystem,  and  a  Database  Transformation  Subsystem. 

1.3. 2. 3.1  Display  information  is  provided  through  a  Data  Base 
Transformation  Subsystem.  The  Update  Console  Subsystem  consists  of 
vendor  supplied  equipment  including  a  radar  display,  a  monochrome 
graphics  terminal,  and  radar  controls  emulated  by  a  digitizing  tablet. 
Hard  copy  devices  for  the  radar  display  and  monochrome  graphics 
terminal  are  also  included. 
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1.3. ^.3. 2  The  Radar  Simulation  Subsystem  generates  the  simulated 
radar  image  from  transformed  data  on  the  238  megabyte  discs.  The  Data 
Base  Transformation  Subsystem  is  a  computer  program  that  operates  on  a 
Defense  Mapping  Agency  (DMA)  computer  system  in  St.  Louis,  Missouri. 
This  program  validates  and  certifies  DMA  terrain  and  culture  data  and 
transforms  it  for  use  within  the  DRLMS. 

1.3. 2. 3. 3  Interface  to  the  OFT  is  via  Shared  .Memory.  The  CPS  is 
organized  into  five  functional  areas  which  include  System  Executive 
Programs,  Real-Time  Operational  Programs,  Data  Base  Modification 
Programs,  Maintenance  and  Test  Programs,  and  Support  Programs. 

1.3. 2. 3. 4  The  CPS  is  coded  in  FORTRAN  with  the  exception  of  a  few 
modules  which  are  coded  in  assembly. 

1.3.2. 4  Visual  System:  The  training  capability  of  the  OFT  is 
enhanced  by  a  Visual  System  which  provides  realistic  training  in 
take-off  and  landing  operations,  with  a  specialized  capability  for 
air-to-surf ace  and  air-to-air  tactical  operations.  A  repeater  of  the 
visual  scene  including  all  Heads-Qp  Display  (HUD)  symbology  is  located 
at  the  instructor  station. 

1.3. 2. 4.1  A  Vital  IV  System  is  used  by  EPAF  (produced  bv  McDonnell 
Douglas  Electronics  Systems  Corporation  -  MDESC)  .  A  Sinaer-Link  Night 
Visual  System  (NVS)  is  utilized  by  the  USAF  pending  update  to  the 
Evans  and  Sutherland  SPX  system  currently  being  implemented  on  the 
F-16  OFT. 


1.3. 2. 4. 2  The  CPS  for  both  systems  (Vital  IV  and  E&S  SPX)  is 
proprietary  since  both  were  procured  as  Commercial  Off-The-Shelf 
(COTS)  systems.  Only  the  visual  scene  databases,  therefore,  will  be 
addressed  in  this  document. 


1.3. 2. 4. 3  The  Vital  IV  interface  module  VOOl  is  an  integral  part  of 
the  CPS  for  the  F-16  A/B  OFT.  As  such,  it  comes  under  TSSC 

TTS 


configuration  management. 

1 , 4  Definitions /Abbreviations 
1.4.1  Definitions: 


/9/P 


a.  Block  Update:  A  revision  level  update  to  the  software 
product  baseline.  This  update  will  normally  include  a  block  of 
previously  approved  TSSC  generated  software  changes  which  are  held 
until  it  becomes  practical  and  cost  effective  to  distribute.  Some  of 
these  changes  may  have  been  previously  distributed  as  temporary 
changes.  A  Block  Update  cycle  of  one  year  is  a  scheduled  goal. 

b.  Command  Certification.  A  statement  of  requirement  from  the 
office  of  change  authority  of  any  command,  country  or  other  User 
consisting  of  an  official  request  for  a  specific  type  hardware  and/or 
software  modification  to  the  current  master  product  baseline 
configuration. 
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c.  Computer  Software  Configuration  Item  <'CSCI).  A  CSCI  is 
aggregation  of  software  or  any  of  its  discrete  portions,  which 
satisfies  an  end  use  function. 


d.  Computer  Program  System  (CPS) 
computational  software  program  product 


The  total  simulator 
including  all  operational 


an 


-4a- 


support,  diagnostic  and  real-time  software  programming  and  media  as 
defined  by  the  Computer  Program  Product  Specification  (CPPS) . 


e.  Computer  Program  Identification  Number  (CPIN) :  A  variable 
length,  alphanumeric  identification  for  control  and  management  of 
Mission  Critical  Computer  Resources  (MCCR)  software  in  the  Air  Force. 

f.  Configuration  Control.  The  systemic  evaluation; 
coordination;  approval  or  disapproval;  and  implementation  of  ail 
approved  changes  in  the  configuration  of  a  Configured  Item. 

g.  Configuration  Status  Accounting.  Recording  and  reporting  of 
the  information  that  is  needed  to  manage  configuration  effectively 
including  a  listing  of  the  approved  configuration  Identification  'the 
status  of  proposed  changes  and  the  implementation  status  of  approved 
changes . 


h.  Development  Technician  Team  (DTT) .  Using  command  technical 
support  personnel  skilled  in  Simulator  Technology. 


i.  Emitter  Identification  Data  (EID) .  The 
known  radar  threats  that  may  be  encountered  in  a 
These  are  stored  in  memory  (PROMS,  EPROMS,  HAM.  e 
reprogramming  action. 


EID  represent  the 
hostile  environment, 
tc.)  and  can  undergo 


J.  Hardware  Product  System  (HPS) .  The  physical  training  device 
hardware  design  product  as  defined  in  the  Prime  Item  Fabrication 
Specification,  configured  Engineering  Drawing  set,  other  associated 
technical  documentation  and  as  defined  in  the  TSSC  contract  Statement 
of  Work  (SOW) . 


k.  Mission  Critical  Computer  Resources  (MCCR) .  All  computer 
e<fuipment ,  programs,  data,  documentation,  personnel  and  supplies 
Integral  to  a  defense  system  from  the  design,  acquisition,  operations 
and  support  point  of  view.  This  excludes  general  purpose, 
commercially  available  automatic  data  processing  equipment  used  for 
administrative  data  processing. 


1.  Operational  Flight  Program  (OFP) .  The  software,  used  for 
control  of  aircraft  avionics  computers,  which  perform  computations  and 
™^hes  logical  decisions  related  to  mission  performance  and  aircraft 
contro 1 . 


ra.  Product  Baseline  (PB) .  The  composite  trainer  system 
conf  iguratlon.  database  constating,  of  the  Computer  Program  System  (CPS 
-  software,  firmware  and  associated  technical  data)  and  the  Hardware 
Product  System  (HPS  -  Engineering  Drawings,  Support  Equipment, 
associated  technical  data  and  spares  etc)  as  defined  in  the  TSSC 
contract  SOW  and  Air  Force  Documentation. 

n.  Product  Team  (PT) .  The  complement  of  logistics  and  technical 
personnel  having  00-ALC  responsibility  for,  and  dedicated  to,  the 
logistical  support  and  management  of  F-16  training  devices.  This 
group  was  originally  organized  as  an  F-16  Product  Team  ’Cell*  under 
00-ALC/MMI  Trainer  Division,  but  was  relocated  under  the  F-16  Weapon 
Systems  Division  (00-ALC/MMA)  in  June  1989.  This  cell  or  team  la  now 
known  as  the  F-16  Training  Devices  Logistics  Product  Team  (  referred 
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to  hereafter  aimpiy  aa  the  F-16  Product  Team  or  Just  ’Product  Team’) 
and  includes  00-ALC/MMAMT  (Logistics)  and  MMARE- 1  and  -2 
(Engineering).  (Para  2.2.2) 

o.  ATD  Project  Officer  (PO)  .  The  individual  designated  as 
liaison  between  the  Government  and  the  Contractor  Logistics  Support 
(CLS)  Contractor  with  the  responsibility  for  assuring  base 
participation  in  providing  logistics  and  administrative  support  of  the 
Aircrew  Training  Devices.  (See  Para  t.  TSSC  Liaison  Engineer) 

p.  ATD  Quality  Assurance  Representative  (QAR) .  The  Government 
individual  who  exercises  surveillance  over  the  quality  of  the  CLS 
Contractor's  work  to  make  sure  that  the  contractor  has  properly 
accomplished  all  work  tasks  in  accordance  with  contract 
specifications.  (See  Para  t.  TSSC  Liaison  Engineer) 

q.  Separately  Procured  Modification  (SPM) .  A  change  to  the 
Product  Baseline  that  is  beyond  the  capabi 1 i ty/acope  of  the  TSSC  or 
would  extend  beyond  the  contractual  period. 

r.  Software  validation.  Evaluation,  integration  and  test 
activities  conducted  at  the  system  level  to  ensure  that  the  developed 
software  satisfies  requirements  set  down  aa  performance  and  design 
criteria  in  the  system  specification  and  oper at  1 onal /support 
requirements . 

з.  Training  System  Support  Center  (TSSC).  An  ATD  support 
function  normally  staffed  by  the  Contractor  Logistic  Support  (CLS) 
contractor.  Under  the  direction  of  00-ALC/MMA,  the  TSSC  performs 
configuration  management,  configuration  status  accounting,  and  general 
update  of  the  Product  Baseline  (PB) .  This  function  is  currently 
located  in  Bldg  1264  at  Hill  AFB . 

t.  TSSC  Liaison  Engineer  (TLE) :  00-ALC/MMA  engineer  who  will 
interface  with  the  TSSC  contractor  personnel.  This  function  also 
includes  the  duties  of  the  Project  Officer  (PO)  and  Quality  Assurance 
Representative  (QAR)  for  TSSC  functions.  The  ATD  PO/ATD  QAR  will 
handle  TSSC  equipment  maintenance  issues. 

и.  Temporary  Change:  A  temporary  software  change  to  the  User 
Site  (working)  copy  of  the  ATD  CPS  .  These  changes  may  be  distributed 
between  Block  Updates  to  enhance  training  capability  of  the  ATD  In  a 
timely  manner.  Such  changes  will  be  permanently  incorporated  into  the 
CPS  as  part  of  the  next  Block  Update. 

V.  Time  Compliance  Technical  Manual  (TCTM)  .  The  time  limited  •*" 
technical  manual  directing  installation  of  a  permanent  change  to  the 
product  baseline  at  the  User  Sites  aa  generated  and  distributed  by  the 
TSSC  contractor  under  MMAMT  direction.  Since  Air  Force  Technical 
Orders  are  not  applicable  under  the  CLS  concept,  the  TCTM  is  the  TSSC 
contractor’s  document  filling  the  same  requirement. 
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A  r  rlr.  z  (Air  r*  o  r  c  ■£?  R  •=:  i:  i"*  v  'r  s  ) 
Re q u  1  r *5 me n  1 3  a.nd  Deveiopmen-i  Of  fic*^ 
Aircrew  Training  Devices. 


•--."/RE!?.,  Air  .“orce  ! 
Rcint  01  Con"ac' 


or  af?e; 


2.0.3  ;jaB  CJationai  Guard  Sureauj  :  .MGB/XOPM  is  the  Point  o r^nr--, 

:  or  Air  Mationai  Guard  Aircrew  Training  E^evices.  *' 

-.0.9  European  Participating  Air  Forces  (EPAFs). 

-.0^9.1  Belgiu.t  Air  Force  •  E.AF)  :  The  .-r.anag emen t  focai  ooint  •'--.r  ^-••d 
so: -ware  is  t.te  avionics  section  oi  the  BAF  Air  staff  (VDT/E)  ’oc'ted 
in  Brussels,  Belgium.  The  Belgian  Liaison  office  at  00-ALC  'VMA-L-PFI 
will  act  as  an  interface  between  the  BAF  Air  staff  and  U£AF  '  ^ 

organi zaLions . 

2. 0.9. 2  Royal  Danish_Air  Force  (RDAF):  The  .management  focal  -oint 
.-r  .--.o  soitware  i.-.  RD.Ar  is  t.ne  Air  .Materiel  Command  f.AMC)  Air-'raf* 
Division.  ."-10  dranch  (FMK/TYF)  .  The  AMC .  located  at 
/aerioese.  Danmark,  is  responsible  for  Logistics,  eng ineer rn^and 
.maintenance  support  as  well  as  finance  and  planning,  and  as  such  will 
provice  r-lo  software  iiaison  to  USAF  and  r-16  MNF?  Air  Forcc.^- 
r.D AF  w w R  at  0 0 *" a L L / MMA 'L'JE  will  coordinate  AF 

MCCB  ana  SCCEB .  -  "  .- -r  t . .. . pat  i  on  on  tne 


2.0. 9. 5  Royal  .Netherlands  Air  Force  (RMLAF);  The  RNLAF/Dire^r  a-,.-- 
01  Materiel  (DMKLu)  is  located  in  the  Hague.  The  F-16  Pr  o  j  ec  t  "n  f  i  i  c.- 
IS  tne  oiiice  of  primary  responsibility  for  the  RHLAF  F-16  orogram 
rocai  and  coordination  point  for  F-16  is  the  Avionics  Section  (VL'-')  f 
the  Aircraft  Engineering  and  Logistics  Branch  ( AVL) .  office  symbol  ' 
DMKLu/ AVL/VL2.  The  .RMLAF  will  participate  as  a  minimum  in  the  MCCB 
and  dCLLB  as  aelineated  in  the  F-16  WST  CRISP  t.hrough  OO-.ALC/MMA-L-.VE . 

2. 0.9. 4  Royal  Norwegian  Air  Force  (RNOAF):  The  H.MOAF  Material 
Command  located  at  KJeiler,  Morway  is  responsible  for  logistics 
technical  and  .maintenance  support  ,  as  well  as  finance,  or-^anication 
ana  Planning.  Aeronautical  Division,  Avionics  Branch ’( TFA)  ,  will  b- 
m(!,!  "'1^  WST  coordination  and  focal  point.  The  RMOAF  SCR  at  00-ALC/ 
..1MA-u-;IO  wii.  coorainate  .-NIOAr  participation  in  the  MCCB  and  SCCSB. 

2.0.10  Air  Training  Co^nd  (ATC)  .  ATC  is  responsible  for  providing 
Air  .  orce  training  including  training  curriculum,  manuals  and 
schedules,  both  for  pilots  in  the  simulators,  and  training  of 
maintenance  and  support  personnel. 

2.0.11  Air  Force  Operational  Teat  and  Evaluation  Center  (AFOTEC) 
AFOTEC  is  responsible  for  the  operational  test  and  evaluation  of  ail 
new  acquisitions  to  verify  acquired  equipment  is  functional  within  the 
scope  OI  Air  Force  specifications,  and  that  it  meets  reliability  and 
maintainability  requirements. 

2 . 1  Control  Boards,  Panels  and  Groups 

2.1.1  Multinational  Computer  Resources  Working  Group  (MCRWQ) .  The 
MCRWQ  is  responsible  for  management  and  update  of  the  F-16  Weaoon 
System  (aircraft)  Computer  Resources  Integrated  Support  Plan  (CRISP) 
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and  0/S  CMP.  This  group  is  also  responsible  for  review  and 
implementation  of  aircraft  software  Operational  Flight  Programs  (OFPs) 
as  approved  by  the  SCCSB. 


2. 1.1.1  Training  Devices  Multinational  Computer  Resources  Working 
Group  (TDMCRWG).  The  F-16  TDMCRWG  is  responsible  for  management  and 
update  of  the  F-i6  ATD  0/S  CMP  and  training  devices  Mission  Critical 
Computer  Resources  (MCCR)  configuration  concurrency  with  the  aircraft 
software  OFP  configurations. 


2.1.2  F-16  WST  Users  Group  (WSTUG):  The  F-16  WSTUG  was  established 
by  the  F-16  Multinational  Fighter  Program  Operations  Sub  Committee 
(OSC)  June  1986.  The  purpose  of  the  WSTUG  is  to  review  the  overall 
program  direction.  Screen  proposed  changes,  assign  priorities,  and 
otherwise  provide  guidance  for  F-16  WST/aircraft  configuration 
concurrency . 

2. 1.2. 3  EPAF  F-16  WST  Pre-Users  Group:  The  four  EPAF  countries  wil 
hold  a  Pre-Users  Group  meeting  in  country  as  required,  prior  to  the 
scheduled  WSTUG  meeting.  Purpose  of  this  meeting  is  to  organize 
information  of  common  interest  (i.e.  Service  Deficiency  Reports, 
problems  etc)  to  be  presented  at  the  WESTUG  meeting.  Prioritization 
of  Enhancement  type  change  requests  is  of  prime  importance  and 
consensus  among  participants  is  desireable.  Pre-User  Group  meeting 
minutes  will  be  taken  and  copy  provided  00-ALC/LIRBE  prior  to  the 
scheduled  WSTUG  meeting. 


2.1.3  Computer  Software  Screening  Panel  (CSSP):  The  change 
classification  screening  function  referred  to  in  AFR  800-14  and 
designated  as  the  Computer  Software  Screening  Panel  (CSSP)  in  AFLCR 
800-21.  For  the  F-16  Training  Devices  program,  this  function  will  be 
accomplished  by  the  F-16  Product  Team.  (Para  2.2.2) 


2.1.4  00-ALC/MM/MMA  Configuration  Control  Board/Mul tinational 
Configuration  Control  Board  (00-ALC  CCB/MCCB):  Upon  program 
Management  Responsibility  Transfer  (PMRT)  of  any  F-16  system/subsystem 
to  Ogden,  the  00-ALC  CCB/MCCB  (hereafter  referred  to  as  the  "MCCB**)  is 
the  configuration  change  control  authority  for  all  such  F-16 
U . S . /Mul tinational  Participating  Air  Force  changes  as  currently 
designated  in  00-ALCR  57-2,  and  has  the  responsibility  for  all  changes 
to  the  assigned  system  and  its  Configuration  Items  (Cl). 


2. 1.4.1  F-16  Software  Configuration  Control  Sub-Board  (SCCSB): 


a.  The  F-16  SCCSB  (formerly  known  as  the  Computer  Program 
Configuration  Control  Board  -  CPCSB)  operates  under  the  authority  of 
the  MCCB  for  training  devices  as  prescribed  in  AFR  800-14  and  AFLCR 
800-21. 


b.  The  SCCSB  will  have  primary  responsibility  to  exercise 
configuration  management  and  control  of  each  PMRTd  ATD  CSCI  and  is 
the  approval  authority  for  Class  I  and  II  CSCI  changes  not  exceeding 
two  million  dollars  in  cost  or  requiring  less  than  15  man  years 
(organic)  or  five  million  dollars  and  25  man  years  (contractual). 
Changes  exceeding  these  limits  will  be  approved  at  the  MCCB  or  higher 
authority  level. 
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c.  The  SCCSB  will  convene  as  directed  by  the  chairperson. 

2.1.5  Control  Group  Interface  Structure:  The  interface  structure 

of  these  groups  as  pertains  to  change  implementation  at  the  Oser  Sites 
is  provided  in  Figure  2-1. 

2 . 2  Organization  Responsibilities 

2.2.1  WSTDG  Organizational  Structure:  The  WSTUG  is  chaired  by 
00-ALC/MMAMT  and  consists  of  primary  members  from  TAG  and  the  EPAF 
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F-16  WEP'N  SYSTEM  >  ISEPARATELY  PROCURED 
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Flo  2-1,  F-16  ATD  Change  Organization  Structure 


»  MCCR  Representative 


2. 2. 5. 3  Meetings:  At  a  minimum,  this  group  will  meet  semiannually  in 
conjunction  with  the  MCRWQ ,  but  any  participating  organization  may 
request  the  chairman  to  convene  the  working  group. 

3.0  COHFIGHRATION  MAHAaEMEHT  C0HCEPT2 

3.1  Change/Dlscrepancv  Claaslf Icatlons  and  Priorities;  Change 
requests/dlscrepancy  reports  to  Computer  Software  Configuration  Items 
(CSCIs).  and  hardware  must  be  controlled  in  an  efficient  and 
responsive  manner;  yet,  provide  the  flexibility  required  to  meet 
mission  requirements. 

3.1.1  CSCI  Change  Classification:  CSCI  changes  are  classified  as 
Class  I  (design)  and  Class  II  (discrepancy)  changes,  as  defined  in 
Appendix  XIV  of  MIL-3TD-483A . 

3.1.2  Hardware  or  Combined  Hardware / So f tware  Change  Classification: 
Any  change  Involving  hardware  only  or  combined  hardware/sof tware  will 
be  classified  in  accordance  with  APR  57-4. 

3.1.3  Change  Discrepancy  Priorities:  Priority  will  be  assigned  by 
the  F-16  Product  team  in  coordination  with  the  Users  according  to  the 
following  guidelines. 

3. 1.3.1  Priority  E  (Emergency)  . 

3.1.3. 1.1  An  emergency  priority  will  be  assigned  if  immediate 
resolution  of  the  request  la  essential  to  prevent  a  serious  compromise 
of  national  security,  fatal  or  serious  Injury  or  illness  to  personnel, 
extensive  loss  of  damage  of  equipment,'  or  severe  restriction  of 
degradation  of  combat  readiness. 

3.  1.3.  1.2  Such  change  must  be  completed  within  72  hours  and  will 
1^  the  interest  of  ti me ,  be  i mp lamented  as  a  te mp o r a r y 
change  by  the  TSSC  pursuant  to  approval  by  the  SCCSB. 

3.  1.3.  1.3  Coordination  with  the  change  originator  on  E  priority 
requests  will  be  accomplished  via  electrical  .message  direct  from  the 
P**16  Product  Team  with  information  copies  to  the  Command  ’  s/Country  *  a 
primary  member  of  the  WSTUQ. 

3. 1.3.2  Priority  U  (Urgent). 

3. 1.3. 2.1  An  urgent  priority  will  be  assigned  if  prompt  resolution  of 
the  request  is  essential  to  prevent  either/or  serious  degradation  to 
the  mission  effectiveness  of  deployed  equipment,  potential  Injury  to 
personnel  or  damage  to  equipment,  program  schedule  slippage  or 
increased  cost,  or  a  lost  opportunity  for  significant  lifecycle  coat 
savings. 

3. 1.3. 2. 2  Upon  review  and  approval  by  the  Product  Team,  Urgent  type 
changes  must  be  corrected  within  10  working  days  as  a  temporary 
change . 
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3. 1.2. 2. 3  Coordination  or  urgent  change  requests  will  be  accomc i ished 
oy  tne  Product  Team  through  normal  command  channels.  Direct 
communication  may  be  required  with  the  change  originator  concernina 
technical  details. 

3. 1.3. 3  Priority  R  (Routine). 

3. 1.3. 3.1  K  Routine  priority  will  be  assigned  to  all  requests  which 
do  not  meet  the  criteria  tor  Emergency  or  Urgent 

3. 1.3. 3. 2  Coordination  will  be  accomplished  as  outlined  in  these 
procedures . 

3.1.4  Electronic  Warfare  Integrated  Reprogramming  (EWIR)  Changes 

(USAF  Only):  The  following  subsections  describe  the  types  of 

Aircraft  EWIR  changes  as  specified  in  APR  55-90.  EWIR  changes  may 
occur  periodically  as  a  aircraft  block  update  change  or  may  be 
directed  as  an  emergency  change.  Technical / intel 1 igence  data  for  real 
world  emergency  changes  and  e.xercises  are  transmitted  according  to 
distribution  identified  in  this  document. 

3.1. 4.1  Type  U  (User).  Change  is  accomplished  by  the  user  and  is 
restricted  to  a  change  i.n  tactics  equipment  setting,  etc.,  that  does 
not  affect  software  or  hardware  configuration.  00-ALC  serves  in  an 
advisory  capacity  to  users  on  requests  to  assist  in  evaluation. 

3. 1.4. 2  Type  L  (Logistics).  00-ALC  is  responsible  for  determining 
feasibility,  designing,  coding,  testing,  and  releasing  type  L  changes 
in  Electronic  Warfare  Systems  and  Ground  Support  Equipment  (GSE) . 

3.1. 4.3  Type  S  (System).  Type  S  changes  are  normally  hardware  system 
changes  using  the  ECP  process  and  will  be  processed  in  accordance  with 
APR  57-4. 

3.1.5  Trainer  Priorities  for  EWIR  Changes:  The  priority  stated  in 
the  change  request  will  establish  the  work  schedule  and  level  of 
effort  required  to  support  the  change.  Usually,  the  priority  will  be 
assigned  as  E.  U  or  R  as  noted  above. 

3.1.6  Mission  Data  Changes:  Changes  in  site-peculiar  mission  data 
will  be  accomplished  by  the  CLS  Contractor/EPAF  site  personnel.  Each 
CLS  site  will  be  under  the  direction  of  the  ATD  PO.  The  TSSC  may  be 
tasked  by  the  F-16  Product  Team  to  maintain  common  Sensor  Databases 
such  as  DRLMS  Site/Real -Time  databases,  and  Visual  databases. 
Approach/Departure  plates,  etc  may  also  be  included. 

3.1.7  User  Site  Configuration  Control:  Configuration  control  of  User 
Site  software  configuration  shall  be  in  accordance  with  procedures 
outlined  in  Addendum  D  of  this  0/S  CMP. 

4 . 0  MOD I F I CAT ION/ CHANGE  PROCEDURES 

4.0.1  General:  The  F-16  ATD  Modification/Change  procedure  paragraphs 
outlined  below  correspond  to  like  numbers  on  Figure  4-1.  Change 
Requests  not  affecting  system  configuration  such  as  database 
updates/mission  changes  will  be  handled  by  the  on-site  CLS  contractor 
or  on-site  EPAF  personnel. 
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FIGURE  4-1  MODIFICATION/CHANGE  FLOW 


t  .  1 


Reporting  Regui remen ta . 


4.1.1  Modif ication/Diacrepancy  Report  Sources:  Proposed  changes 
and  discrepancy  reports  on  the  F-16  ATD  may  be  identified  by  any  of 
the  sources  listed  below.  They  may  originate  as  Operational  Change 
Requirements  (OCR’s) .  as  a  result  of  modifications  to  an  aircraft 
system,  from  system  deficiencies,  or  from  proposed  system 
enhancements . 

a.  -.Veapon  System,  Electronic  Warfare  or  Trainer  System  Program 
Manager  (SPM) 

b.  'Jsing  Command  Field  Units  via  the  .4TD  Quality  Assurance 
Representative  (QAR) 

c .  DTT 

d.  TSSC 


4.1.2  Submittal  Procedure;  All  Change  Requirements/Requests  will  be 
submitted  to  the  F-16  Product  Team  (00-ALC/MMAMT)  as  outlined  below. 
This  change  requirement  will  usually  be  submitted  following  the 
receipt  and  review  of  a  rough  draft  'I.mpact  and  Cost  Sharing/Funding 
Package"  (reference  para  4.2. 1.3). 

a.  F-16  Aircraft  Concurrency  Changes.  A  Change  Requirement  may 
be  submitted  as  a  Program  Management  Directive  (PMD) .  Command 
Certification  (AF  Form  1067),  etc.  The  Change  Requirement  will  be 
reviewed  and  processed  in  accordance  with  AFLCR  800-21  Chapter  4, 
00-ALCR  800-22,  and  procedures  outlined  herein. 

b.  Software  Deficiency  Reports  (SDRs),  Material  Deficiency 
Reports  (MDRs)  and  Enhancements  (trainer  unique).  All  SDRs,  MDRs 
and  Enhancements  will  be  reported  and  processed  in  accordance  with 
standard  T.O.  00-35D-54  procedures. 

c.  TSSC  and  DTT  Change  Requests.  Change  Requests  originating 
with  the  TSSC  or  DTT  will  be  submitted/reported  to  the  Liaison 
engineer . 

4 . 2  F-16  Product  Team  Processing: 

4.2.1  Aircraft  Concurrency  Changes:  The  F-16  Product  Team  is 

responsible  for  identifying  and  implementing  change  requirements  to 
ATDs  resulting  from  changes  to  the  aircraft.  •"  •  •  - -  - 

4.2. 1.1  The  F-16  Product  Team  receives  a  copy  of  all  aircraft 
Engineering  Change  Proposals  (ECPs) /Organic  Change  Proposals  (OCPs) 
from  the  aircraft  ECP  Monitor  (MMARS) . 

4.2. 1.2  The  F-16  Product  Team,  with  the  assistance  of  the  TSSC, 
reviews  each  ECP/OCP  for  potential  ATD  applicability  and  logs  into  a 
Logging  and  Tracking  Database.  Tracking  under  the  Material 
Improvement  Project  (MIP)  system  will  be  accomplished  using  the 
assigned  Aircraft  MIP  number. 
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4.2.  1.3  For  any  ECP/OC?  vjith  potential  i. Tip  act  to  an  ATD,  a  rough 
drait  ’Inipact  and  Cost  E  har  i  ng  /  Fund  i  n  g  PacKage  <  AFLC  Forms  13  and  75}' 
13  prepared  and  presented  to  TAF  for  Command  Certification. 
Coordination  and  certification  for  the  E?AF  users  will  be  accomplished 
at  the  Aircraft  Modification  Review  Panel  (MRP) .  Further  screening 
type  activity  pertaining  to  need,  priority  and  implementation 
method/scheduie  will  be  accompiished  through  the  quarterly  newsletter 


^ara 
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and  inclusion  as  agenda  .items  at  the  W2TUQ  meetings. 


4 . 2 . 1 . 4  For  those  ECPs/OC?s  approved  for  implementation  by  TAF  and 
EPAF  users,  a  Final  ‘Impact  and  Cost  Ehar i ng / Fund ing  Package  (AFLC 
Forms  13  and  75) ‘  is  prepared  and  presented  to  the  MCCB  for  approval. 


4,2.2  SDR,  MDR  and  Enhancements :  F-16  Product  Team  processing  and 

responsibilities  for  these  potential  change  requirements  are  as 
follows: 


4.2.2.  1  The  F-lb  Product  Team  will  establish  a  Material  Improvement 
Project  (MIP)  for  SDRs.  MDRs  and  Enhancements  requiring  a  Design 
Change  to  the  ATD .  A  Design  Change  is  defined  as  any  change  to  the 
ATD  which  causes  it  to  operate/ f unct i on  differently  than  specified  by 
the  design  and  product  spec i : i cat i on  .  Coding  Errors  and 
i.mplementation  Errors  are  excluded. 

4. 2. 2. 2  A  Block  Update  ‘Candidate  Mumber‘  will  be  assigned  to  each 
potential  Design  Change  to  the  ATD.  Further  discussion  of  these  Block 
Update  Candidates  at  the  W2TUQ  and  MCCB  will  reference  this  number. 

4. 2. 2. 3  The  F-16  Product  Team,  with  the  assistance  of  the  TSSC ,  will 
prepare  a  briefing  package  for  each  candidate  for  presentation  to  the 
WSTUG . 

4. 2. 2. 4  MIPS  and  Candidate  Mumbers  will  not  be  assigned  to  ATD  change 
requirements  related  to  Coding  Errors/ Implementation  Errors  unless  the 
scope  of  the  change  will  require  an  effort  beyond  the  core  work  level 
of  the  TSSC. 

4.2. 2. 5  The  F-16  Product  Team  and  TSSC  will  prepare  and  distribute  a 
quarterly  newsletter  to  keep  the  ATD  community  informed  of  upcoming 
candidates,  results  of  MRP  actions  pertaining  to  specific  candidates, 
and  any  other  pertinent  information  between  WSTUG  Meetings. 

4.2.3  TSSC/DTT  Change  Requests:  Potential  change  candidates 
originating  with  the  TSSC  or  DTT  will  be  screened  and  processed 

in  accordance  with  procedures  of  Para  4.2.2,  the  same  as  for  SDRs  and 
MDRs  . 

4.2.4  Priorities:  A  priority  will  be  assigned  to  each  change 
reques t/requirement  according  to  the  definitions  in  section  3.1.3. 

The  priority  will  determine  the  relative  speed  at  which  a 

reques t/requirement  is  reviewed,  evaluated,  developed  and  implemented. 
The  proposed  priority  is  assigned  by  the  originator  and  will  not 
change  unless  a  different  priority  is  negotiated  with  the  originator. 

4.3  Priority  E  and  IT  Processing:  Priority  E  and  U  Change 
Requirements/Reques ts  will  be  immediately  tasked  to  the  TSSC  for  work. 
The  originator  and  each  Command ' s/Country ' s  primary  member  of  WSTUG 
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will  be  coordinated  with  by  phone  or  message.  The  change  will  be 
Implemented  as  a  Temporary  Change  pending  the  next  Block  Update. 


Vengus  Implementation  Error  Changea:  In  order  to 
expedite  the  change  process,  different  procedures  will  be  used 
design  versus  coding  and  implementation  error  change  requests 


for 


4.4.1  Coding  Error/ Implementation  Change:  If  a  change  request  is 
aeterminea  to  be  a  result  or  a  coding  or  i  mp  1  emen  t  a  1 1  on  error,  th»^ 
change  request  will  normally  be  tasked  to  the  T22C  for  work  arid" 

1  mp  1  ^^men  ta  1 1  o  n  .  implementation  will  be  by  a  Temporary  Change  or  held 

for  the  next,  Block  Update.  If  the  scope  o:  the  change  will  r<-qulre  an 
effort  beyond  the  core  work  level  of  the  T2SC  .  the  change  request  will 
be  presented  to  the  WSTUG  for  approval  prior  to  expending  resources  to 
correct  the  problem. 


4.4.2  Design  Changes:  If  the  change  request  is  determined  to  require 
a  design  cr.ange  to  the  ATD  such  as  an  aircraft  concurrency  change  or 
an  enhancement,  the  change  request  will  be  presented  to  the  WSTUG 
prior  to  tasking  the  TSSC .  Aircraft  concurrency  changes  may  have 
previously  been  command  certified  and  approved  by  the  MCCB/SCCSS  but 
will  still  be  presented  at  the  next  WSTUG. 


4 . 5  WSTUG  Action; 


4.5.1  00-ALC  Responsibilities.  The  F-16  Product  Team  and  TSSC  will 
assume  the  following  responsibilities  at  the  WSTUG; 

4.5.  1.1  Brief  the  progress  of  previously  approved  ECPs/OCPs  and  Block 
Update  Candidates. 

4.5. 1.2  Prepare  and  present  briefings  for  each  aircraft  ECP/OCP 
having  a  potential  impact  on  the  ATD. 

4.5. 1.3  Prepare  and  present  briefings  for  each  Block  Update 
Candidate,  providing  specific  response  to  queries  arising  from  User 
review  of  the  quarterly  TSSC  Newsletter  (Para  4. 2. 2. 5). 

4.5.  1.4-  Assist  the  User  in  screening,  pr i or 1 1 i  =  ing  ,  and  establishing 
a  Candidate  List  for  the  next  Block  Update.  A  Block  Update  may  also 
contain  one  or  more  Aircraft  Concurrency  Changes. 

4.5. 1.5  Chair  the  Meeting,  take  minutes,  and  assign  action 

4.5.2  User’s  Responsibilities.  The  User's  wt 1 1‘ assume  the 
responsibi 1 1 t les  as  members  of  the  WSTUG: 

4.5.2.  1  Screen  all  potential  Block  Update  Candidates  (Including 
Aircraft  ECPs/OCPs)  for  need,  priority,  implementation  method,  etc.  as 
addressed  at  the  MRPs ,  WSTUG  meetings  and  in  the  quarterly  TSSC 
Mews  letter . 

4. 5. 2. 2  Assist  00-ALC  in  establishing  a  Candidate  List  for  the  Next 
Block  Update.  This  may  require  a  vote  of  the  WSTUG  voting  members. 
Voting  members  consist  of  one  representative  from  TAG,  ANQ/AFRES , 
Belgium.  Denmark,  Netherlands,  and  Norway. 


1  tains  , 
f  o 1 lowing 
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4.5.2.J  r.espond  as  necessary  -o  action  items  and  the  quarterly  T22C 
Newsletter  . 


4 . 6  MCCB/SCSSB  Action: 

4.6.1  Change  Approval:  Ail  changes  to  the  ATD  Product  Baseline  must 
be  approved  by  the  MCCB/SCC2B. 

4.6.2  Change  Package:  The  r-16  Product  Team  will  develop  the 
required  AFLC  Forms  13  and  75  Package  for  review,  approval,  or 
disapproval  in  accordance  with  AFLCR  800-21  for  each  Block  Update. 

4.6.3  Temporary  Changes:  Changes  previously  distributed  as  Temporary 
Changes  will  be  included  in  the  next  scheduled  Block  Update. 

4 . 7  Implementation  -  TSSC : 

4.7.1  Prototype  Effort:  For  those  approved  change  requests  which  are 
within  the  scope  of  the  CLS  TSSC  Contract,  the  TSSC  will  be  tasked  to 
design,  develop,  prototype,  and  document  the  change. 

4.7.2  Validation:  The  F-16  Product  Team  Liaison  Engineer  and  DTT  (as 
requested)  will  validate  the  change  and  also  ensure  that  the 
documentation,  configuration  control,  and  status  accounting  functions 
have  been  properly  completed. 

4.7.2.  1  Generally,  the  Kill  AFB  F-16  A/B  ATD  in  building  IIB  will  be 
the  validation  site.  However,  any  other  USAF/EPAF  site  or  contractor 
facility  may  be  used  if  necessary.  Discrepanc i es  identified  during 
validation  will  be  recorded  and  tracked  by  the  F-16  Product  Team  until 
resolved . 

4. 7. 2. 2  Quality  Assurance  (QA)  provisions  for  changes  to  existing 
software  will  be  in  accordance  with  those  used  during  the  procurement 
of  the  ATD.  Any  new  software  will  be  evaluated  against  D0D-STD-216a 
Quality  Assurance  requirements.  The  F-16  Liaison  Engineer  will 
accomplish  the  QA  tasks. 

4. 7. 2. 3  Independent  Verification  and  Validation  ( IVStV)  will  be 
accomplished  by  the  F-16  Liaison  Engineer. 

4.7.3  Integration  Responsibi 1 i ties .  The  TSSC  is  responsible  for 
maintaining  the  Product  Baseline.  In  support  of  Separately  Procured 
Modifications  (SPMs) ,  the  TSSC  will  participate  in  providing  the  SPM 
contractor  reference  data  and  implementing  the  final  product. 

4.7.3.  1  Upon  direction  from  the  F-16  Product  Team,  the  TSSC  will 
provide  a  copy  of  the  Product  Baseline  software  media  and 
documentation  to  the  SPM  Contractor. 

4. 7. 3. 2  The  TSSC  will  participate  in  Design,  In-Process  Documentation 
Reviews,  Program  Management  Reviews,  and  validation  of  SPCs  when 
requested  by  the  F-16  Product  Team.-  If  the  SPM  contractor  is  the  same 
company  as  the  TSSC  contractor,  the  F-16  Product  Team  will  perform  the 
above  reviews  and  validation. 
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4. 7, 3, 3  The  TSSC  will  Integrate  the  changes  from  the  SPM  contractor 
into  the  Product  Baseline.  In  most  cases,  this  will  involve  taking 
the  new  validated  Product  Baseline  from  the  SPM  contractor  and  addinu 
any  TSSC  changes.  ^ 

4 . 8  Implementation  -  Contractual: 

4.8.1  Activation: 


4.8. 1.1  For  Those  modifications  that  are  out  of  scope  of  the  TSSC. 
the  Product  Team  will  initiate  action  for  competitive  or  sole  source 
contract  or  procurement  in  accordance  with  AFR  57-4  proceduresT 

4.8.  1.2  F-16  Product  Team  engineering  will  generate  the  required 
data/lnformatlon  (Description  of  Services.  Statement  of  Work  (SOW), 
stc.)  for  competitive  or  sole  source  procurement. 


4.8. 1.3  F-16  Product  Team  Production  Management  personnel  will 

generate  required  Jus 1 1 f Icat 1  on/ Author i zat 1  on  (JiA)  and  Purchase 
Requests,  and  submit  the  package  to  the  office  of  Contractual 
Procurement  (00-ALC/PMZET) .  For  competl tlve- type  contractual  efforts. 
F-i6  Product  Team  technical  personnel  will  participate  in  development' 
of  the  bid  package  and  sit  on  the  source  selection  panel  for  sell 
of  the  contractor. 


.  ec 1 1  on 


4.8. 1.4  Upon  receipt  of  the  procurement  package,  PMZET  will  complete 
and  process  either  a  competitive  bid  or  sole  source  package,  as 
applicable,  and  award  a  contract  to  a  contractor. 

4.8. 1.5  Both  the  software  and  engineering  data  Product  Baselines 
(Master  Disk  Packs  and  engineering  drawings)  to  be  used  as  the 
baseline  by  the  contractor  will  be  obtained  from  the  TSSC  (Para 

4 .7.3. 1)  . 


4.8.2  Implementation;  The  contractor  will  develop  the  modification, 
update  the  Product  Baseline,  produce  the  required  TCTM,  Install  kits 
at  user  sites  per  requirements  of  the  contract  CDRL ,  and  provide  the 
new  Product  Baseline  (includes  documentation)  to  the  TSSC. 

4.9  TSSC  Diatr Ibution : 

4.9.1  Temporary  Changes. 

4.9. 1.1  Temporary  Changes  may  be  distributed  to  USAF/EPAF  sites  on 
floppy  disk  or  magnetic  tape  with  installation  procedures.  This 
distribution  will  b'e  accomplished  with  the  approval  of  the  using 
commands  and  these  changes  will  only  be  installed  on  the  Site 
(working)  disk  packs.  For  EPAF .  Foreign  Disclosure  Policy  Office 
(FDPO)  coordination  will  be  obtained  as  appropriate. 

4.9. 1.2  Temporary  Changes  will  not  require  an  update  to  the 
documentation  and  will  not  require  CPIN  updates.  However,  a  Temporary 
Change  will  be  included  in  the  next  Block  Update  and  will  then  be 
fully  documented  and  CPINs  updated. 


4.9.2  Block  Updates. 


4. 9. 2.1  Block  Updates  will  be  scheduled  annually.  However,  the  scope 
of  a  given  change  and  other  factors  may  cause  this  schedule  to  change 
slightly.  Block  Updates  will  be  the  official  change  to  the  Product 
Baseline  and  will  include  all  Temporary  Changes  that  have  not  been 
previously  incorporated  into  the  Product  Baseline.  The  TSSC  will 
archive  copies  of  the  Product  Baseline  two  revisions  back. 

4. 9. 2. 2  The  TSSC  will  prepare  AF  Forms  1243  (CPIN  Data)  necessary  for 
the  Software  Control  Canter  (SCO  to  update  the  USAF  CPIN  compendium. 

4. 9. 2. 3  The  TSSC  will  deliver  a  copy  of  the  software  media  and 
related  software  documentation  to  the  SCC . 

4.9.2. 4  The  TSSC  will  deliver  a  copy  of  all  other  technical 
documentation  and  engineering  drawings  to  the  Stock,  Store,  and  Issue 
Center  (SSIC). 

4.9.3  USAF  Users:  Distribution  of  software  media  and  all 
documentation  (software  &  hardware)  to  USAF  Users  will  be  made  by  the 
TSSC  and  SSIC.  The  F-16  Product  Team  will  coordinate  this  action  with 
the  SCC. 

4.9.4  EPAF  Users:  Distribution  of  software  media  and  related  \ 

software  documentation  to  EPAF  Users  will  be  made  by  the  SCC  via  the  ' 
CPIN  system.  All  EPAF  users  must  submit  an  initial  AFTO  form  157  (Ref 
T.O.  00-5-17)  through  their  Technical  Order  Distribution  Office  (TODO) 
to  the  SCC  to  establish  the  initial  software  update  requirement  and/or 
receive  software  and  associated  documentation  for  the  initial 

change  requirement.  This  is  normally  in  response  to  receipt  of  a  TCTM 
from  the  TSSC.  Once  the  AFTO  form  157  has  been  submitted,  it  will  not 
be  required  on  future  distribution  requirements  from  this  User.  / 

4. 9. 4.1  Upon  receipt  of  these  requests,  the  SCC  obtains  appropriate 
F-16  Product  Team  and  any  required  Foreign  Disclosure  Policy  Office 

( FDPO )  coordination.  EPAF  requests  with  coordinations  are  forwarded 
to  OC-ALC/MMDUC  for  processing  (authorization  of  signature  and 
sufficient  funds  in  Country  Case). 

4. 9. 4. 2  Upon  receipt  of  mailing  labels  (AFTO  forms  221  and  273)  from 
OC-ALC/MMDUC,  the  SCC  makes  distribution  to  TODOs . 

4. 9. 4. 3  All  EPAF  users  are  billed  for  software/documentation 
distribution  costs  through  the  CPIN  system.  The  SCC  establishes 
software  distribution  costs  (blank  media  plus  reproduction  time)  for 
each  CSCI  received  in  the  CPIN  system.  EPAF  billing  for  modification 
development  is  outlined  in  Addendum  C,  "EPAF  Cost-Sharing 
Methodology" . 

4.9.5  Hardware  Documentation:  Distribution  of  hardware  documentation 
will  be  through  the  SSIC, 

4.10  Separately  Procured  Modification  (SPM)  Contractor  Distribution: 

4.10.1  Temporary  Changes.  Temporary  Changes  will  not  be  used  by  the 
contractor. 
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4.10.2  Block  Updates. 


4  10  '  The  oontrictoi-  will  prepare  AF  Forms  1213  (TFIII  Bata) 

necesla^y  tor  the  SCC  to  update  the  UCAF  CFIH  compendium. 


10.2.  -  ills  U-iliWlSi.'-w-.  -  -- 

aseiine  media  a.nd  related  soitware  aocumentat ton 
SC  . 

4  10  2  3  The  contractor  will  deliver  the  modified  hardware 

documentation  to  the  TSSC  and  tne  iSiC. 

4.10.2.1  Distribution  to  the  User  sites  will  be  in  accordance  with 
the  contract . 

.  ,,  .,4-irhTi  VATiiftcation:  Upon  completion  of  installation  of  a 

-•  -T  date"  the  CLS/TSSC  contractor  will  submit  AFTO  rorm  349  to 

OQ-iLC^'/U4AMT’  and  USAF  users  will  report  installation  in  the  next 
m'oVd  Service  Report.  Z?AF  Users  will  report  installation  status  by 
message  to  00-.4.LC /MMAMT .  No  formal  response  will  be  requirea^for 
’  nst’^  '  =-tion  of  a  Temporary  Change.  However,  the  user  sites  wi 
iaintiln  a  local  record  of  all  Temporary  Changes  installea. 

5 . 0  STATUS  ACCOUUTINa 

5  1  HenortingReauizements^  The  F-16  Product  Team  is  r espons ib 1 e  f or 

.  j  ,  ,  4  n'rf  and  analysing  all  aircraft  changes  which  may  impact  the 

iln"  iiditionally  the  Team  has  responsibility  for  receiving  and 

chinSP  Pepuecpc  cuch  ap  MDEa  .  alrcmalt  ECP-a,  ate.  Theaa 
tracking  tracked  throughout  the  appro val/disapproval 

And^iodiflcatlon  process.  The  TSSC  has  responsibility  for  tracking  _ 

H  naoorting  any  modifications  made  to  the  product  baseline. 

•(  f  ^nnallv  the  TSSC  may  track  and  report  changes  to  non-conf  igurea 
dlti  iuch  a^’DRLMS  dLa  bLes  .  Visual  data  bases  etc.  as  specifically 
tasked  by  a  User  through  the  Product  Team  (I/IMAMT)  . 


-ho  contractor  will  deliver  a  copy  of  the  new  Product 


the  TSSC  and  the 


5  ^  2  ?^tatus  Accounting  System. 


5  2  1  Status  of  Change  Requests:  Change  Reques ts  wi 1 1 . be  entered 

ir.i^\nd  tracked  by  the  G021  (MIP)  report ing/ tracking  system  i^ 
Additionally  The  F-16  Product  Team  will. receive  all 
cr'i^RecuestMinog  into  an  internal  identification,  logging  and 
tracking  system.  Data  such  as  Change  Type.  Change  Humoer .  Source , 
Srour^pprovkl,  Command  Car  1 1 1  Icat  Ion  .  MOCB/SCCSB  acaion.  and 

completion  date  will  be  tracked. 

K  o  o  status  of  Change  Requests  Approved  for  Implementation: 

and  tnalk  tha  status  oi  all  CPS  modi  1  Idat Ions  using  tha 

aSrino-^ :: 

diti^g^^v  a^?-rd“c;jB  z-a^r^y"‘iL^t:tnrArij:^ii:3‘t:  iAa 

see  requesting  revisions/corrections . 
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o'  t*  I'j  P-  fj  *  ^  ’L) 


Status  oi  Sensor  and  Visual  Databases: 
accounting  on  a.l  sensor  catabases  sue 


lata,  etc.  Tnis  status 
each  'user  site,  databas 
by  location,  type,  and 


a c c 0 un t  mg  w ill 
es  available  at 
serial  n  umb  e  r . 


COMMUNICATION  RSQUIUEJ/IENTS 


DRLMt! 


.  -  o  e  r  I  0  r  m 


data.  Visual 


tabases  available  at 
and  tracking  of  media 


Slectrical  Communications . 


V  W 


.  1  DEFENSE  SWITCHED  NETWORK  (DSN)  : 

p  r  o  V 1  c  e  a  via  t  n  '-i  ^  *  n  ^  ^ 

ccmmunicate  sscureiy  -.vi^h  'hs  uaiing 


■£ec’-ire  e  i  ecommun  i  cat  i  ons  will 
n3 ^ r’ar.en ’la  :ar  TSSC  pirsonnsl 
commands  and  W?:-ALC. 


5.1.2  AOTODIN:  English  language  -exw  messages  will  be  used  tc 

-.ransmit  operaaionai  instrucaions  and  related  data  for  changes  via 
AUTODIN. 


".0  SECURITY 


7.1  Security  ?/ianagement .  Poroicns  of  th 
EECP.ET  based  upon  oha  F-15  Aircraft  Securi 
.--15  WST  and  TSSC  operaoion ,  including  IDS 
ri.noouis.  are  considered  classified  until 
etermination .  Security  provisions  will  b 
0Q~u5  The  TC2C  facility  will  be  adscuat 
lassiiied  information  up  to  and  including 
s  provided  with  the  CPS  for  declassifying 
isks  by  overwritting  the  entire  media  sur 
DOt  checking  the  media. 


e  W2T  CPS  are  classified 
ty  Classii ication  Guide, 
displa'/s  and  hardcopy 
reviewed  for  unclassified 
e  i.n  accordance  with  AFR 
e  for  use  and  storage  of 
SECRET.  A  computer  program 
hard  disk  packs  and  floppy 
face  three  times  and  then 


^2  Item  Class!  f  icat  ion .  Items  will  be  classified  in  accordance  with 
he  F-ld  Aircraft  Security  Class! f icat ion  Guide  and  reieasability  will' 
e  determined  in  accordance  with  applicable  Deletion  Disclosure 
Letters  (DDLs ) .  • 

3.0  APPLICABLE  DOCUMENTS 


3  .  1  Ref  er ences  . 


AFR 

50-1  1 

Management  and  Utilisation  of  Training 
Devices 

AFR 

65-3 

Configuration  Management 

AFR 

57-1 

Statement  of  Operational  Needs  (SON) 

AFR 

57-4 

Modification  Program  Approval  and 
Management 

AFR 

aoo-4 

Transfer  of  Program  Management 
Responsibility 

AFR 

CD 

O 

o 

Life  Cycle  Management  of  Computer 
Resources  in  Systems 

AFR 

300-19 

System  or  Equipment  Turnover 
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AFLCR  800-21 


00-ALCR  57-2 

00-ALCR  300-3 

00-ALCR  800-22 

TACR  800-3 

AFR  65-32 
AFR  55-90 
MOA  (6  Jun  1976) 

EWIR 

8 . 2  Military  Standarda 
MIL-STD-480 

MIL-STD-481A 

MIL-STD-483  (USAF) 

DOD-STD-2167 
DOD-STD-2168 
0 . 3  Forma 

AF  Form  1067 
AF  Form  1775 

AFLC  Form  48 
AFLC  Form  75 


Management  and  Support  Procedures 
for  Computer  Resources  used  in 
Defense  Systems 

Configuration  Management  Procedures 
(Class  IV  and  V,  27  Oct  33) 

Management  of  Computer  Resources  m 
Sys  terns 

Acquisition,  Management  and  Support  of 
Computer  Resources  in  Systems 

ATD  Acquisition,  Testing  and 
Modification  Management 

DOD  Configuration  Management 

Electronics  Wariare  Policy 

Government  of  the  United  States 

and  the  government  of  Belgium,  Denmark. 

Netherlands  and  Norway 

Headquarters  USAF  Electronic  Warfare 
Integrated  Reprogramming 


Corn*  i gur 

ation 

Control  - 

Engineering 

Changes , 

Deviations , 

,  and 

Waivers 

Conf i gur 

ation 

Control  - 

Engineer ing 

Changes , 

Deviations , 

,  and 

Waivers 

(Short  F 

orm) 

Conf Igur 

ation 

Management 

Practices 

Sys terns , 

Equipment  , 

Mum 

tions  and 

Computer  Programs 

Defense  System  Software  Development 
Defense  System  Software  Quality  Program 


Modification  Proposal 

Engineering  Change  Motlce/Sof tware 
Problem  Report 

Class  IV  Modification 

SCCSB  Item  Record 
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AF  Form  1243 
DD  Form  173 
AFTO  Form  157 
AFTO  Form  349 


CPIN/ AFCRI  ^nd  Control  Rocorfl  — 

Joint  Message  Form 
Request  for  Software  Distribution 
Maintenance  Data  Collection  Form 
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ADDENDUM  A. 


ABBREVIATIONS  AND  ACRONYMS 


A 


1 


ABBREVI ATIOMS  AMD  ACRONYMS 


AFLC 

AFLCR 

AFOTEC 

AFM 

A  FREE 

AFR 

AGR 

AFSC 

ALC 

AMC 

AMUX 

ASD 

ATC 

ATD 

BAF 

BU 

CADC 

CARA 

CCB 

CDRL 

Cl 

CIU 

CLS 

COMUS 

CPCSB 

CSCI 

CSSP 


Air  Force  Logistics  Command 
AFLC  Regulation 

Air  Force  Operational  Test  and  Evaluation 
'-'I  e  n  t  e  r 

Air  Force  Man ua 1 
Air  Force  Reserves 
Air  Force  Regulations 
Air  to  Ground  Ranging 
Air  Force  Systems  Command 
Air  Logistics  Center 
Air  Material  Co mma n d 
Avionics  Multiplex  Bus 
Aeronautical  System  Division 
Air  Training  Command 
Aircrew  Training  Device 
Belgian  Air  Force 
Block  Update 

Central  Air  Data  Computer 

Combined  Altitude  Radar  Altinuter 

Com  igurat  ion  Control  Board 

Contract  Data  Requirements  List 

Com  iguratlon  Item 

Central  Interface  Unit 

Contractor  Logistics  Support 

Continental  United  States 

Computer  Program  Configuration  Sub-Board 
(No  longer  used  -  see  3SCSB) 

Computer  Software  Configuration  Item 

Computer  Software  Screening  Panel 


A 


p  I M 


CPS 

CR 

:ri£f 

:  RWG 

L'DLS 

DMA 

DOD 

DRLMS 

DTT 

m  r  T 

J. 

£C? 

EID 

EPAF 

EW 

EWIR 

EWTD 

FCC 

F  CNP 

FCR 

FMS 

HP'S 

HUD 

ILC 

INS 

lOS 

vJ  A 


Computer 

Computer 

Computer 

Comput  er 
Plan 


r'rogram  ident  1 1  ication  Number 

Product  System 

P.esources 


iiesouvc^s 


i  r.  t  e  4 1'  1 6  d  Supper^, 


Computer  Resour cea  Working  Group 

D  e  i  e  g  a  1 1  c-  n  Disclosure  L  e  1 1  a 

Delense  Mapping  Agency 

U e p a p t me nt  ot  Detense 

Digital  Radar  uandmass  System 

Development  Technician  Team 

Data  Trans  I  er  Tnit 

ongineerin^  Change  Proposal 

Emitter  Iden t i f i ca t i on  Data 

turopean  Participating  Air  Force 

Electronic  '.Van' are 

Electronic  Warfare  Integrated 
Heprogramming 

Electronic  Warfare  Training  Device 

Fire  Control  Computer 

Fire  Control  Navigation  Panel 

Fire  Control  Radar 

Foreign  Military  Sales 

Hardware  Product  System 

Head  Up  Display 

International  Logistics  Center 
Inertial  Navigation  System 
Instructor  Operator  Station 
Justification  and  Authorization 
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LOG 

Logistics  Operationai  Center 

MCCB 

Multinational  Cent iguration  Control  Board 

MCCR 

Mission  Critiaai  Computer  Resources 

MCRWG 

Multinational  Computer  Resources  Working 
Group 

MDESC 

McDonnei  Douglas  Electronics  Systems 
Corpora t ion 

MDR 

Ma teriel  Deficiency  Report 

MIP 

Material  Improvement  Project 

MIS 

Management  Information  System 

MO  A 

Memorandum  of  Agreement 

MEWTD 

Morwegian  Electronics  Warfare  Training 
Device 

WV£ 

Night  Visual  System 

OCR 

Operational  Change  Request 

OFF 

Operational  Flight  Program 

OFT 

Operational  Flight  Trainer 

OO-ALC 

Ogden  Air  Logistics  Center 

OPR 

Office  of  Primary  Respons ibi 1 i ty 

0/S  CMP 

Operational/Support  Conf iguration 
Management  Procedures 

PACAF 

Pacific  Air  Forces 

PMRT 

Program  Management  Respons i b 1 1 1  ty 

Trans  f  er 

PO 

Pro j  ect  Of  £ icer 

PTC 

Pro'gammabie  Terminal  Controller 

QA 

Quality  Assurance 

QAR 

Quality  Assurance  Representative 

RDAF 

Royal  Danish  Air  Force 

REO 

Radar  Electro-Optical 

RNOAF 

Royal  Norwegian  Air  Force 
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HNLAF 

SAMT 

see 

seesB 

SCE 

SCP 

sow 

SPM 

SPM 

TAG 

TAP 

TAWe 

TeTM 

TDMCRWG 

TSSC 

aSAF 

USAFE 

WR-ALC 

WST 

WSTUG 


Royai  Netherlands  Air  Force 
Simulated  Aircralt  Maintenance  Trainer 
Software  Control  Center 

Software  Con i i 4ur a t i on  Control  Sub-ooard 

Signal  Conversion  Equipment 

Stores  Control  Panel 

Statement  of  Work 

System  Program  Manager,  or 

Separately  Procurred  Modification 

Tactical  Air  Command 

Tactical  Air  Forces  (TAC,  PACAF  and 
USAFE) 

Tactical  Air  Warfare  Center 

Time  Compliance  Technical  Manual  (CLS) 

Training  Devices  Multinational  Computer 
Resources  Working  Group 

Training  System  Support  Center 

United  States  Air  Force 

United  States  Air  Force  in  Europe 

Warner  Robins  Air  Logistics  Center 

Weapon  System  Trainer 

Weapon  System  User's  Group 
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COTS 

CRXilP 

DI;uV 

ECI.I 

200 

I'OPO 

032 

IVfirV 

JARr.I 


Commercial  Off  The  Shelf 

oomputer  ilasotirsea  Lifecycle  Ivlanagoaient  Plrm 

Lircct  Memory  Access 

Electronic  Counter  Measure 

2n,']:ineerin.'3  Change  Order 

Porci.-ui  Diaclofiure  Policy  Office 

Ground  Support  Equiment 

Independant  Verification  &  Validation 

Jamnicr, Artillery, Radar,  illsailB 


MRP  Modification  Review  Panel 


MOTJ 
RGB 
OSC 
PivID 
P3 

PROM 

PT 

RAM 

RWR 

SCMS 

SDR 

SSIC 

TCG 

TO  DO 

Y/STUG 


Memorandum  Of  Understanding 

National  Guard  Bureau 

Operationa  Sub  Committee 

Program  Management  Directive 

Product  Baseline 

Programable  Read  Only  Memory 

Product  Team 

Random  Access  Memory 

Radar  Yearning  Receiver 

Standard  Configuration  Management  Syatem 

Software  Deficiency  Report  ^ 

Stock, Store  and  lasue  Center 

Technical  Coordination  Group 

Technical  Order  Distribution  Office 

./eapon  System  Trainer  User's  Group 
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1.0 


INTRODUCTION 


1.1  Scope  and  Purpose 

Software  for  the  OCU  Trainer  is  managedby  OO-ALCT-IRBE  and  changed  by  the  Training  System 
Support  Center  (TSSC).  Tnis  includes  operational  software  for  the  Operational  Flight  Trainer 
(OFT)  and  Digital  Radar  Landmass  System  (DRUMS).  Radar  landmass  databases  for  the  DRUMS 
are  aiso  included.  The  purpose  of  these  guidelines  is  to  establish  a  common  set  of  definitions  and 
procedures  for  managing  any  future  changes  to  the  operational  software  and  DRUMS  databases  at 

the  using  sites. 

2.0  GENERAU 

2.1  Operational  Software  and  Database  Changes 

Aircraft  changes,  recommended  enhancements,  and  discrepancies  will  result  in  TSSC  developed 
software  changes  to  the  above  training  devices.  .Additionally,  radar  landmass  databases  are  still 
being  updated'for  recently  added/modirled  terrain  and  cultural  features.  In  order  to  field  changes 
quic^y,  changes  to  the  operational  software  will  be  sent  to  sites  on  a  floppy  disk  with  installation 
instructions  (Temporary  changes)  when  practical.  These  changes  may  be  applied  to  your  site 
baseline  (see  later  definition)  and  may  be  used  for  training.  The  extent  of  the  changes  may 
sometimes  dictate  a  revision  level  update  to  the  Product  Baseline  (Block  Update)  with  new  300MB 
packs  Updates  to  the  DRUMS  database  will  include  a  new  S-RDDB  (Site)  300MB  disk  pack.  The 
site  will  then  have  to  build  a  R-RDDB  (RT)  pack  from  this  S-RDDB  disk  using  the  Mission 
Generation  capability  of  the  DRUMS. 


2.2  Site  Software  Configuration  Controller 

It  is  recommended  that  a  Site  Software  Configuration  Controller  (SSCC)  be  established  at  each 
training  site.  This  individual  should  be  familiar  with  both  the  NORSK  DATA  SINTRAN  III 
Operating  System  and  the  Uink  Configuration  Control  Software.  The  SSCC  will  ensure  that  the  Site 
Baseline  Is  not  corrupted  by  unauthorized  modifications  and  will  also  be  responsible  for  installing 
any  changes  received  from  the  TSSC.  The  SSCC  should  also  be  responsible  for  making  mission 
related  changes.  It  is  recommended  that  the  individual  selected  as  the  SSCC  identify  himself  to  the 
TSSC.  A  good  working  relationship  berween  the  TSSC  and  the  SSCC  will  help  ensure  successful 

updates  to  the  software. 

3.0  OFT  REQUIREMENTS  and  DEFINITIONS 

3.1  Site  Disk  Pack  Requirements 

There  should  be  a  minimum  of  eight  configured  and  one  scratch  300  MB  disk  packs  dedicated  to 
each  OFT.  Tne  configured  packs  should  be  labeled  as  outlined  below,  since  the  TSSC  will  refer  to 

them  by  these  names:  , 
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a.  Product  Baseiine  Disk  Set  (PBDS).  Tne  PBDS  is  a  copy  oc  the  Air  Force  Product 
Baseline  maintained  at  the  TSSC-  Tnis  disk  set  should  be  secured  in  a  safe  location  and  only  be  used 
for  coovin§  purposes.  Chan§es  should  never  be  made  to  this  disk  set.  At  Oontractor  Logistics 
Suooort  fCLS)  sites  this  disksetshould  be  under  the  direct  controi  of  the  project  officer.  The  PBDS 
consists  of  the  following  disk  packs; 

1)  OPERATIOKS 

2)  SYMD 

b.  Site  Master  Disk  Set  (SMDS).  The  SMDS  is  a  copy  of  the  PBDS  which  has  been 
modified  at  the  site  to  include  mission  data  and  any  temporary  changes  provided  by  the  TSSC.  This 
disk  set  is  the  Site  Baseiine  referred  to  in  paragraphs  2.1  and  2.2.  The  SMDS  consists  of  two  copies 
eac.T,  one  copy  designated  “MASTER  SMDS”  and  one  copy  designated  “BACKUP”.  The  SMDS 
consists  of  the  following  disk  packs: 

1)  OPERATIONS  (Master  and  Backup) 

2)  SYMD  (Master  and  Backup) 

c.  Site  Operational  Disk  Set  (SODS).  The  SODS  is  a  copy  of  the  SMDS  OPERATIONS 
Master  pa.ck.  This  pack  is  the  reai-time  training  pack.  The  SODS  consists  of  the  following  disk 

pack: 

i  1)  OPERATIONS  (2  copies  recommended) 


321  OFT  SOFTWARE  UPDATE  PROCEDURES 

3.2.1  Block  Updates  and  Temporary  Changes 

Sites  will  receive  software  updates  as  revision  level  updates  to  the  Product  Baseiine  (Block 
Updatesias  new  300  MB  diskpac.ks  or  as  updates  on  floppy  disk  (Temporary  Changes).  The  intent  or 
Temporary  Changes  is  to  provide  quick  solutions  to  software  deficiencies/enhancements  without 
requiring  documentation  updates  and  regeneration  of  site  mission  data  (required  for  Block  Updates). 


3.2.1.1  Block  Update  Procedures 

A  Block  Update  is  a  new  revision  level  update  to  the  Air  Force  Product  Baseiine.  This  update  will  be 
received  as  300MB  disk  packs  labeled  as  the  Produa  Baseiine  Disk  Set  (PBDS).  The  following 
procedures  should  be  followed  by  the  SSCC  for  each  Block  Update: 

a.  Examine  the  new  disk  packs  for  physical  damage,  including  shock  watch 
activation.  If  the  packs  appear  to  be  undamaged,  copy  the  new  PBDS 
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OPERATIONS  disk  to  a  scratch  disk  and  bring  up  the  real-time  load  using 
the  scratch  disk.  If  any  obvious  problems  are  observed,  contact  the  TSSC  and 
do  not  proceed  any  further. 

b.  Copy  the  new  PBDS  disks  (OPER.-^IONS,  SYMD)  to  the  MASTER 
SMDS  disks. 

c.  Install  your  site  mission  changes  on  the  MASTER  SMDS  disks. 

d.  Copy  the  MASTER  SMDS  OPERAHONS  disk  to  the  scratch  disk. 

e.  Using  the  scratch  disk,  bring  up  the  real-time  load  and  verify  that  the 
mission  changes  were  made  correctly.  Repeat  steps  b.  through  e.  if  necessary 
to  get  a  correct  load. 

f.  Copy  the  MASTER  SMDS  disks  to  the  BACKUP  SMDS  disks. 

g.  Copy  the  MASTER  SMDS  OPERATIONS  disk  to  the  SODS 
OPERATIONS  disk. 

h.  Declassify  the  replaced  PBDS  disks  and  the  scratch  disk  using  the 
Declassify  Program  as  follows: 

1.  Spin  up  OPERATIONS  pack  on  drive  0.  Load  SINTRAN. 

2.  Spin  up  pack  to  be  declassified  on  drive  1. 

3.  In  User  System; 

@RT  DSCLR  <cr> 
disk  type  =  3 
unit  =  1 
continue  =  y 

Verify  that  all  software  changes  reported  in  the  Version  Description 
Document  work  accordingly.  Report  any  discrepancies  to  the  TSSC. 

FAX:  (801)  825-2627 

Phone:  (801)825-2650 

3.2.1J!  Temporary  Changes 

Temtwrary  Changes  are  intended  to  provide  quick  solutions  to  sofrit^ 
discrepancies/enhancements.  The  changes  will  usuaUy  be  provided  as  source  code  on  a  floppy  disk 
and  will  include  a  Mode' file  which  will  automatically  perform  the  update  process  for  the  user,  if 
practical.  Included  with  the  floppy  will  be  both  a  paper  and  an  electronic  copy  of  the  Temporary 
Chance  Document  which  details  the  procedures  for  installation  of  the  Temporary  Change  on  the 
SMDS.  The  following  procedures  should  be  followed  for  each  Temporary  Change: 
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a.  Install  the  Temporary  Change  on  the  MASTER  SMDS  disks  as  instructed. 

Note  that  changes  should  never  be  made  to  the  BACKUP  SMDS.  The 
BACKUP  SMDS  should  only  be  used  for  copying. 

b.  Copy  the  MASTER  SMDS  OPERATIONS  disk  to  a  scratch  disk. 

c.  Using  the  scratch  disk,  bring  up  the  real-time  load  and  test  the  installed 
chanees.  If  the  update  failed,  copy  the  BACKUP  SMDS  disks  to  the 
MASTER  SMDS  disks  and  repeat  steps  a.  through  c.  until  the  update  is 
installed  correctly. 

d.  Copy  the  MASTER  SMDS  disks  to  the  BACKUP  SMDS  disks. 

e.  Copy  the  MASTER  SMDS  OPERATIONS  disk  to  the  SODS 
OPER.ATIONS  disk  and  declassify  the  scratch  disk. 

3.3  Reporting  Problems 

Software  problems  should  be  reponed  to  OO-ALC  via  the  MDR  system.  Prior  to  submitting  a 
MDR,  the  problem  should  be  verified  as  being  a  software  problem  with  the  PBDS.  If  the  problem 
appeared  after  installation  of  a  temporary  change,  make  a  note  of  this  in  the  MDR. 


4.0  DIGITAL  RADAR  LANDMASS  SYSTEM  (DRUMS) 

4.1  Site  Disk  Pack  Requirements 

There  should  be  a  minimum  of  three  75  MB  disk  packs  and  four  300  MB  disk  packs  dedicated  to 
DRUMS.  The  disk  packs  should  be  labeled  as  follows: 

1)  DRUMS  Product  Baseline  OPER.ATIONS  (75  MB)  (1  each) 

2)  DRUMS  Site  OPERAnONS  (75  MB)  (MASTER  and  BACKUP) 

3)  DRUMS  S-RDDB  (Site)  Database  (300  MB)  (MASTER  and  BACKUP) 

4)  drums  R-RDDB  (RT)  Database  (300  MB)  (MASTER  and  BACKUP) 

4.2  DRUMS  Product  Baseline  OPERATIONS  Disk 

Changes  to  DRUMS  Operational  software  contained  on  the  OPERATIONS  disk  pack  are  not 
anticipated.  However,  if  changes  are  made,  a  new  DRUMS  Product  Baseline  OPERATIONS  disk 
will  be  sent  to  applicable  sites.  This  disk  should  be  stored  in  a  safe  location  and  should  never  be  used 
for  training  purposes.  At  CLS  sites,  the  ProjectOfficer  should  control  this  baseline.  This  diskshould 
only  be  used  to  build  Site  OPERATIONS  packs  by  copying. 

4  j  DRUMS  Site  OPERATIONS  Disks 
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These  packs  are  copies  of  the  DRLMS  Configuration  Master  OPERATIONS  disk  with  changes  to 
directory  tiles  which  match  the  DRLMS  R-RDDB  (RT)  database  and  are  used  for  training.  These 
directory  files  are  updated  whenever  a  new  DRLMS  R-RDDB  (RT)  Database  disk  is  generated 
using  the  Mission  Generation  task  of  DRLMS. 

4.4  DRLMS  Site  Database  Disk  (S-RDDB) 

This  disk  contains  Radar  Digital  Data  of  requested  areas  of  Defense  Mapping  Agency  (DMA)  data. 
The  S-RDDB  may  then  be  enhanced  as  necessary  by  the  Small  Area  Update  task  and  used  to  build  a 
real  time  gaming  area  disk  pack  (R-RDDB)  using  the  Mission  Generation  task.  There  is  oniy  a  128 
ceil  maximum  capacity  for  each  S-RDDB  disk  pack,  therefore,  depending  on  individual  site 
requested  coverage,  the.  possibility  exists  that  a  site  may  have  several  S-RDDB  disk  packs.  Fnrh 
disk  is  built  and  delivered  by  the  TSSC,  and  the  Backup  is  generated  on  site  by  copying. 

4.5  DRLMS  R-RDDB  (RT)  Database  Disks 

These  disks  contain  the  Real-Time  Radar  Digital  Data  used  for  generating  the  ground  map  radar 
return  during  a  mission.  The  MASTER  disk  is  generated  from  data  contained  on  the  S-RDDB 
by  denning  a  gaming  area  during  the  Mission  Generation  task.  The  BACKUP  is  a  copy  of  this  disk. 

4.6  Requests  For  New  Databases 

Any  requests  for  additional  database  areas  should  be  directed  to  the  TSSC.  If  data  is  available  for  the 
requested  mission  area,  a  new  DRLMS  S-RDDB  MASTER  disk  will  be  built  and  forwarded  to  the 
requesting  site.  A  blank  replacement  300  MB  disk  pack  should  be  returned  to  the  TSSC.  If  data  is 
not  available  for  the  requested  mission  area,  the  Using  Command  will  have  to  make  arrangements 
with  the  Defense  Mapping  Agency  (DMA)  for  the  requested  data  areas  to  be  transformed  and 
forwarded  to  the  TSSC. 
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TSSAs  F14D01  delivery  was  formally  delivered  two  years  after 
prime  system  release,  due  to  continuing  contractor  software 
updates  (final  delivery  Sep  94). 
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1.0  Scope 

This  report  covers  TSSA  software  baseline  deliveries  FY93/F-14D01  and  FY95/F-14D02 
on  the  following  F-14D  training  devices: 

Device  25153  Mission  Flight  Trainer 

Device  2F154  Weapon  System  Trainer 

Tactical  Environment  System 

1 . 1  Purpose 

The  intent  of  this  repon  is  to  address  some  of  the  design  metrics  involved  in  the 
implementation  of  tactical  tapes  DO  1  and  D02  into  the“F-  14D  training  devices.  It  is  hoped 
that  the  information  provided  here  is  useful  not  only  as  a  historical  reference  but  mainlv  as  a 
guide  for  the  implementation  and  measurement  of  future  updates. 

A  ADVEP-HDBK-7  (Rev.  i).  Software  Metrics  Handbook  defines  the  following  software 
\  metrics  as  a  guide  for  software  development  projects: 

1 )  Requirements 

2)  Size 

3)  Staffing 

4)  Quality 

5)  Capacity 

6)  Schedule 

An  effort  has  been  made  to  adhere  to  the  guidelines  provided  in  the  Software  Metrics 
Handbook,  although  this  report  deals  primarily  with  the  basic  software  design  elements  of 
(2)  Size,  and  (5)  Capacity.  An  effort  has  been  made  to  include  some  treatment  of  each  of 
the  other  categories,  but  much  of  this  information  is  not  readilv  available  and  some  must  be 
provided  by  other  TSSA  functions. 

1 .2  Introduction 

The  data  in  this  report  was  derived  primarily  from  two  sources:  baseline  build 
reports/databases  generated  during  development,  and  from  module  difference  listings 
generated  post-development.  The  information  contained  herein  represents  design 
information  incorporated  into  the  DOl  and  D02  software  baselines,  and  design  metrics 
pertaining  to  Source  Lines  Of  Code.(SLOC),  memory  usage,  datapool  sizes,  and  CPU 
frame  time  usage. 

It  should  be  understood  that  the  information  given  here  is  based  upon  the  best  information 
available  and  has  been  organized  after  the  fact:  allowing  tor  certain  inconsistencies  and 
inaccuracies.  The  information  presented  is  representative  of  the  overall  effort,  and  any 
deviations  from  exact  data  is  denoted  as  such.  A  more  comprehensive  studv  could 
alleviate  some  of  this  error,  but  given  the  modest  amount  of  clarification  provided  and  the 
considerable  amount  of  time  which  would  be  required  for  such  an  effort,  anv  inaccuracies 
are  considered  insignificant. 
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2.0  Referenced  Documents 

2. 1  Government  Documents 


ADVEP-HDBK-7  (Rev.  1),  Software  Metrics  Handbook 

2.2  I^on-Government  Documents 

TBD 
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Information  is  provided  in  this  section  summarizing  the  software  design  work  incorporated 
into  each  delivered  baseline. 

3.1  DOl  Design  Incorporation 

Table  A  (below)  lists  all  the  designs  requiring  software  modification  that  were  incorporated 
into  DOl.  It  does  not  include  tactical  designs  that  required  no  specific  TSSA  modifications 
outside  remote  terminal  activation  and  configuration  ID  changes  (a  sub-group  of  RT 
Activation).  All  changes  devoted  to  expansion  of  datapools.  datapool  panitions.  task 
partitions,  task  overlays,  em..  fall  under  the  heading  System  Expansion.  Macro  s  written 
(or  modified)  specifically  tor  TSSA  development  such  as  warmstart  and  directory  backup 
macros  fall  under  that  heading.  All  other  units  that  were  modified  were  and  not  directly 
attributable  to  a  specific  design  fall  under  the  single  category  of  DR  Corrections. 
Miscellaneous,  and  Unknown. 


Control  Number 

FY93/FI 4001-001 

FY93/FI4D01-.XXX 

FY93/FI4D0I-XXX 

FY93/F14D01-0I.02 

FY93/FI4D0I-0I.04 

FY93/FI4D01-0!.05 

FY93/F14D0I-0I.08 

FY93/FI4D0I-01.12 

FY93/F14D01-01.I3 

FY93/F14D0I-01.I4 

FY93/FI4D01-01.17 

FY93/FI4D01-01.18 

FY93/F14D0I-01.19 

FY93/F14D01-0I.2I 

FY93/F14D0I-01.23 

FY93/F14DOI-OL28 

FY93/F14D0I-01.2S 

FY93/F14D01-0I.32 

FY93/F14D01-03 

FY93/F14D01-XXX 


TSSA  Softwnre  Desiiin  Title 
Taciicai  Tape  Drop-in  (RT  Incorporaiion ) 
System  Expansion  (SYSGEN.  RM,  or  DP) 
TSSA  Development  Environment 
Sensor  Control  Mechanization 
JTIDS  Fighter-To-Fighter  DataLink 
ORT  Abort 

Flexible  Missile  Messages 
RWS  Mode  Upgrade 
HRWS  Default  Scan  Selection 
AIM-7M  Second  Missile  Message 
Radiation  Modes  ( RRE) 

Spin  Arrow  Limitation 
HUD  Cagc/Uncage 
Right  Director  Mode 
ALR-67  Radar  Warning  Receiver 
Infrared  Search  and  Track  (IRST) 

Infrared  Search  and  Track  (IRST) 

Multiplex  Bus  Messages 

OBOGS  C/A  Light  Illumination 

DR  Corrections.  Miscellaneous,  and  Unknown 


Table  A 

DOl  TSSA  Software  Designs 


3 .2  D02  Design  Incorporation 


Table  B  (below)  lists  all  the  designs  requiring  software  modification  that  were  incorporated 
into  DO  I .  It  does  not  include  tactical  designs  that  required  no  specific  TSSA  modifications 
outside  remote  terminal  activation  and  configuration  ID  changes  (a  sub-group  of  RT 
Activation).  All  changes  devoted  to  expansion  of  datapools,  datapool  partitions,  task 
partitions,  task  overlays,  etc.,  tall  under  the  heading  System  Expansion.  Macro's  written 
(or  modified)  specitically  tor  TSSA  development  such  as  warmstart  and  directory  backup 
macros  tail  under  that  heading.  .Many  units  were  listed  as  DR  corrections  but  were  not 
identified  with  a  specific  design  and  are  listed  as  Unknown  DR  Corrections.  All  other 
units  that  were  modified  were  and  not  directly  attributable  fall  under  Unknown. 
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Control  Number 

FY95/F-14D02-001 

FY95/F-14D02-XXX 

FY95/F-I4D02-XXX 

FY95/F-I4D02-0L01 

FY95/F-14D02-01.02 

FY95/F-14D02-01.03 

FY95/F-I4D02-01.17 

FY95/F-I4D02-01.27 

FY95/F-14D02-03 

FY95/F-I4D02-06 

FY95/F-I4D02-XXX 

FY95/F-14D02-XXX 

FY95/F-I4D02-XXX 


TSSA  Software  Dpsign  Title 
Tactical  Tape  Drop-In  (RT  Incorporation) 
System  Expansion  (SYSGEN.  RM.  or  DP) 
TSSA  Development  Environment 
Medium  PRF 
Precision  Velocity  Update 
■Air-To-Ground 
JTIDS 

MOARDP  1553  Interface 
Sensor  Display  Indicator  Set 
Engine  Mode  Select  Function 
IRST/VSC 

Unknown  DR  Corrections 
Unknown 


Table  B 

D02  TSSA  Software  Designs 
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4.0  Device  Implementation 

Information  regarding  device  implementation  is  TBD.  Implementation  of  baselines  on  the 
different  F-14D  training  devices  is  not  currently  well  defined  or  documented. 
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5.0  Software  Metrics 

The  goal  of  obtaining  and  tracking  software  metrics  is  to  provide  a  basis  for  measuring 
software  development  progress  and  to  assist  in  the  projection  of  software  project  impact 
and  costs. 

5.1  Requirements 

The  basic  requirements  for  TSSA  design  work  is  the  Trainer  Performance  Specification 
(TPS).  In  lieu  of  the  TPS,  tactical  documentation  serves  as  a  guideline.  See  TSSA 
Configuration  Management  for  D01/D02  TPS's  and  reference  to  tactical  documentation. 

There  is  no  current  effort  to  measure  and  track  requirement  revision  and  scheduling. 

5.2  Size 

The  basic  element  of  software  size  is  Software  Lines  Of  Code  (  SLOC),  both  new  and 
reused. 


5.2.1  Source  Lines  of  Code  (SLOC) 

Table  C  gives  the  SLOC  breakdown  for  ail  DOl  designs  and  Table  D  is  the  corresponding 
table  for  the  D02  effort.  Appendices  A  and  B  lists  the  units  included  for  each  design.  An 
effon  has  been  made  to  identify  new  units  in  the  appendices,  but  no  formal  tracking  of  new 
versus  re-used  code  has  been  made. 

One  item  of  interest  derived  from  the  SLOC  breakdowns  is  the  size  of  effort  involved  in  the 
first  three  categories  (Tactical  Tape  Incorporation,  System  Expansion,  and  TSSA 
Development  Environment).  During  the  DOl  and  D02  development  periods,  those 
categories  accounted  for  approximately  17  and  13  percent,  respectively,  of  the  overall 
efforts. 

Note:  Spreadsheets  are  available  showing  both  the  individual  SLOC  counts  per  unit  and 
the  multiple  designs  impacting  individual  units,  but  were  not  included  in  this  repon. 

Tables  E  and  F  show  the  average  percentage  of  SLOC  modified  for  effected  units  per 
design  (total  modified  SLOC/Originai  SLOC).  The  tables  also  show  the  average  increase 
in  unit  SLOC  per  design.  While  neither  of  these  figures  can  be  directly  related  to  the 
amount  of  new  or  re-used  code,  they  are  indicative  of  the  amount  of  rework  and  code 
added  in  units  for  each  design  effort. 

Note  :  No  effort  was  made  to  separate  individual  SLOC  counts  between  multiple  designs 
impacting  the  same  unit.  SLOC  counts  were  divided  evenly  between  the  multiple  designs. 
It  was  judged  that  the  extremely  time  consuming  task  of  accounting  each  SLOC  change  to 
a  particular  design  (post-development  )  would  have  been  of  insignificant  impact  and  value. 

Note  :  .\11  data  pertaining  to  IRST/VSC  designs  (D01/D02)  are  for  the  Encore  Host 
software  only.  Data  was  not  available  for  the'Silicon  Graphics  software. 
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F-14D01  Designs 


Control  Number 

Pgjign 

%  of  unit 

%  inc  in 

modified 

unit  SLOC 

FY93/F14D01-001 

Tacticai  Tape  Drop-In  (RT Incorporation) 

22 

7 

FY93/F14D01-XXX 

System  Expansion  (SYSGEN,  RM,  or  DP) 

7 

4 

FY93/F14D01-XXX 

TSSA  Development  Environment 

19 

15 

FY93/F14D0I-01.02 

Sensor  Control  Mechanization 

46 

13 

FY93/F14D0I-01.04 

JTIDS  Fighter-To-Fighler  DaiaLink 

14 

10 

FY93/F14D01-0I.05 

ORT  Abort 

41 

7 

FY93/F14D0 1-0 1.07 

Screen  Target  Designate 

32 

10 

FY93/FI4D0 1-0 1.08 

Flexible  Missile  Messages 

43 

16 

FY93/F14D0 1-0 1.12 

RWS  Mode  Upgrade 

31 

6 

FY93/F14D01-01.13 

HRWS  Detauit  Scan  Selection 

108 

43 

FY93/F14D0 1-0 1.14 

AIM-7M  Second  Missile  Message 

12' 

2 

FY93/F14D0 1-0 1.17 

Radiation  Modes  ( RRE) 

27 

14 

FY93/F14D01-01.18 

Spin  Arrow  Limitation 

54 

12 

FY93/F14D0 1-0 1.19 

HUD  Cage/ Uncage 

7 

1 

FY93/F14D0 1-0 1.21 

Flight  Director  Mode 

12 

T 

FY93/F14D0 1-0 1.23 

.ALR-67  Radar  Warning  Receiver 

21 

3 

FY93/F14D0 1-0 1.28 

Infrared  Search  and  Track  (IRST) 

74 

54 

FY93/F14D0 1-0 1.32 

Multiplex  Bus  Messages 

27 

14 

FY93/F14D01-03 

OBOGS  C/A  Light  Illumination 

4 

1 

FY93/F14D0I-XXX 

Unknown  DR  Corrections 

36 

12 

Averages 

27 

il 

Table  E 

Unit  Percentage  SLOC  Modificd/Incrcascd  per 

DOI  Design 

F>14D02  Designs 

Control  Number 

Design 

%  of  unit 

%  inc  in 

modified 

unit  SLOC 

FY95/F-14D02-001 

Tactical  Tape  Drop-In  (RT Incorporation) 

26 

4 

FY95/F-14D02-XXX 

System  Expansion  (SYSGEN,  RM.  or  DP) 

6 

2 

FY95/F-14D02-XXX 

TSSA  Development  Environment 

50 

46 

FY95/F-14D02-01.01 

MPRF 

35 

6 

FY95/F-I4D02-01.02 

PVU 

21 

9 

FY95/F-14D02-01.03 

Air-To-Ground 

33 

20 

FY95/F- 14002-0 1.1 7 

JTIDS 

48 

20 

FY95/F-14D02-01.27 

MQARDP  1553  Interface 

13 

10 

FY95/F-14D02-03 

SDIS 

40 

4 

FY95/F-14D02-06 

Engine  Mode  Select  Function 

146 

5 

FY95/F-14D02-XXX 

IRST/VSC 

243 

130 

FY95/F-14D02-XXX 

Unknown  DR  Corrections 

21 

2 

FY95/F-I4D02-XXX 

Unknown 

16 

5 

Averages 

36 

13 

Table  F 

Unit  Percentage  SLOG  Modified/Increased  per  D02  Design 
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5.3  Staffing 

Personnel  and  Man  Hour  figures  are  TBD. 

5.4  Quality 

Quality  Trend  measurements  are  TBD.  TSSA  software  problem  reports  exist  in  the  fonn 
of  Trainer  Software  Trouble  Reports  (TSTR's)  and  Discrepancy  Reports  (DR's).  Formal 
tracking,  prioritization,  and  final  disposition  are  done  by  CM  and  Systems  groups,  and  no 
effort  was  made  to  obtain  final  data  for  this  report.  This  is  at  least  partly  due  to  the  on¬ 
going  effort  to  clear  outstanding  DR's. 

There  are  no  efforts  to  judge  complexity  of  units,  pre-existing  or  modified. 

5.5  Capacity 

Capacity  measurements  deal  with  computer  resource  usage.  The  data  given  here  is  not 
perceived  to  be  a  complete  picture  of  the  computer  resource  utilization  of  the  training 
device.  It  does  show  the  general  trends  over  the  recent  development  periods  and  points  out 
areas  where  further  study  is  needed. 

ADVEP-HDBK-7  (Rev.  1),  Software  Metrics  Handbook  points  out  three  areas  of  capacity 
measurement: 

a)  processor  throughput  for  each  individual  processing  element 

b)  memory  for  each  type  of  memory  and  for  each  processing  element 

c)  Input/Output,  which  includes  bus  and  frame  timing,  for  each  individual  bus 
or  internal  data  network 

The  F-14D  training  devices  have  utilities  which  measure  spare  memory  and  frame  time  and 
these  are  dealt  with  in  the  succeeding  sections.  The  memory  reports  would  seem  to 
correlate  directly  to  item  b  above.  The  computation  of  frame  time  is  slightly  more 
ambiguous,  but  would  appear  to  correlate  more  to  item  a.  I/O  bandwidth  and  I/O  frame 
timing  measurements  are  not  available. 

Also  included  here  is  a  section  on  datapool  impact.  While  this  is  normally  a  part  of  the 
overall  memory  me^urements,  it  is  of  note  here  due  to  the  significant  impact  on  specific 
datapoois  and  how  it  corresponds  to  the  loss  of  memory  in  related  processors. 
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Spare  Memory  data  is  obtained  from  original  contractor  developed  utilities  and  is  measured 
to  the  nearest  Page  (2048  Byte)  in  size.  The  only  contributing  factor  (non-constant)  in  the 
memory  reports  is  the  CPU  task  size,  which  accounts  for  the  growth. 


Node 

Pre-DOl 

DOl  Final 

D02  Final 

%  chanoe 

A1/A2 

49 

48 

48 

-2.04 

A3/A4 

72 

72 

72 

0.00 

BI/B2 

74 

71 

71 

-4.05 

B3/B4 

39 

39 

38 

-2.56 

B5/B6 

63 

63 

63 

0.00 

B7 

58 

58 

58 

0.00 

C1/C2 

69 

67 

67 

-2.90 

C3/C4 

70 

69 

69 

-1.43 

C5/C6 

52 

50 

50 

-3.85 

C7 

50 

46 

44 

-12.00 

D1/D2 

50 

48 

48 

-4.00 

D3/D4 

69 

67 

67 

-2.90 

D5/D6 

52 

51 

51 

-1.92 

Table  G 

Spare  Memory  Comparison 

Note:  Pre-DOl  data  is  from  early  DOl  baselines  (dated  8/93  and  4/94).  DO  I  Final  data  is 
from  DO  I  B15  (dated  1/95)  and  b02  Final  data  is  from  D02  B 14  (dated  2/96). 
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5.5.2  Datapool  Impact 

Table  H  shows  the  datapool  usage  comparison  for  the  Pre-DOl,  DOl,  and  D02  baselines 
It  also  gives  the  current  spare  ( in  bytes ). 


Datapool 

Dictionarv 

Partition  Size 
fBvtes) 

Pre-DOl 
(Bvtes  1 

DOl  Finai 

(Bvtes ) 

D02  Finai 
(Bvtes ) 

Current  Spare 
IBvtes) 
5501 

MFTOODPD 

65536 

55322 

58616 

60035 

MFTIODPD 

8192 

4388 

4388 

4388 

3804 

MFTllDPD 

114688 

101414 

101423 

101423 

13265 

MFT12DPD 

32768 

18694 

18694 

18694 

14074 

MFT20DPD 

16384 

14898 

14904 

14908 

1476 

MFT2IDPD 

8192 

3916 

3920 

3920 

4272 

MFT22DPD 

8192 

5190 

5204 

5633 

2559 

MFT23DPD 

8192 

5145 

5145 

5J45 

3047 

MFT24DPD 

8192 

2634 

2634 

2'634 

5558 

MFT30DPD 

49152 

38944 

41686 

42582 

6570 

MFT3IDPD 

8192 

5296 

5296 

5295 

2897 

,MFT32DPD 

8192 

2642 

2642 

2642 

5550 

MFT33DPD 

32768 

26715 

26715 

26715 

6053 

MFT34DPD 

32768 

27895 

29246 

30372 

2396 

MFT40DPD 

507904 

497902 

497902 

498840 

9064 

MFT41DPD 

32768 

29343 

29344 

29344 

3424 

MFT42DPD 

8192 

3701 

3702 

4165 

4027 

MFT43DPD 

24576 

20593 

20593 

20593 

3983 

MFT45DPD 

16384 

7022 

8224 

9160 

7224 

MFT5IDPD 

491520 

471543 

471543 

471543 

19977 

MFT52DPD 

131072 

127420 

127420 

128825 

2247 

MFT53DPD 

417792 

385736 

385736 

385736 

32056 

MFT70DPD 

335872 

232958 

232958 

232958 

102914 

MFT80DPD 

221184 

108984 

108984 

108984 

112200 

MFT81DPD 

24576 

19712 

19712 

19712 

4864 

MFT82DPD 

425984 

409624 

409624 

409624 

16360 

MFT83DPD 

196608 

192504 

192504 

192504 

4104 

MFT84DPD 

65536 

56824 

56824 

56824 

8712 

MFT85DPD 

24576 

19712 

19712 

19712 

4864 

MFT86DPD 

425984 

406248 

406248 

406248 

19736 

MFT87DPD 

212992 

192200 

192200 

192200 

20792 

MFT88DPD 

65536 

56584 

56584 

56584 

8952 

VIFT89DPD 

458752 

447412 

447412 

447412 

11340 

MFT90DPD 

278528 

271700 

271700 

271880 

6648 

MFT91DPD 

450560 

441624 

441624 

441624 

8936 

MFT92DPD 

270336 

264984 

264984 

264984 

5352 

Table  H 

Capacity/Datapool  Dictionary 

Table  I  shows  the  percentage  spare  for  the  same  baselines.  It  should  be  noted  that 
percentage  spare  figures  are  based  upon  the  current  datapool  partition  size  and  does  not 
account  for  any  partition  restructuring  that  may  have  occurred  over  the  course  of 
development. 
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Dictionary 

Pre-DOl 

DOl  Final 

D02  Final 

%  an 

MFTOODPD 

%  Snare 

%  Snare 

%  Snare 

16 

11 

8 

Q 

MFTIODPD 

46 

46 

46 

y 

0 

0 

0 

0 

0 

0 

MFTllDPD 

12 

12 

12 

MFT12DPD 

43 

43 

43 

MFT20DPD 

9 

9 

9 

MFT21DPD 

52 

52 

52 

MFT22DPD 

37 

36 

31 

MFT23DPD 

37 

37 

37 

y 

0 

0 

Q 

MFT24DPD 

68 

68 

68 

MFT30DPD 

21 

15 

13 

MFT31DPD 

35 

35 

35 

y 

0 

0 

0 

Q 

MFT32DPD 

68 

68 

68  ^ 

MFT33DPD 

18 

18 

18 

MFT34DPD 

15 

11 

7 

MFT40DPD 

MFT41DPD 

2 

10 

T 

10 

2 

10 

y 

0 

1) 

13 

0 

30 

0 

t 

MFT42DPD 

55 

55 

49 

MFT43DPD 

16 

16 

16 

MFT45DPD 

57 

50 

44 

MFT51DPD 

4 

4 

4 

MFT52DPD 

3 

3 

2 

MFT53DPD 

3 

8 

g 

I 

0 

0 

0 

MFT70DPD 

31 

3! 

31 

MFT80DPD 

51 

51 

51 

MFT81DPD 

20 

20 

20 

MFT82DPD 

4 

4 

4 

u 

0 

0 

0 

0 

0 

0 

0 

0 

0 

0 

0 

MFT83DPD 

2 

2 

2 

13 

MFT84DPD 

13 

13 

MFT85DPD 

20 

20 

20 

MFT86DPD 

5 

5 

5 

MFT87DPD 

10 

10 

10 

MFT88DPD 

14 

14 

14 

MFT89DPD 

2 

2 

2 

2 

2 

2 

MFT90DPD 

MFT9IDPD 

2 

2 

2 

2 

MFT92DPD 

2 

2 

Table  I 

Percentage  Spare/Datapooi  Dictionary 

The  following  items  should  be  noted: 

Rl  ^  Nodes  Al-3, 

Bl-4,  Cl-2,  Dl-2)  has  been  cut  m  half  over  the  D01/D02  efforts. 

2.  ^30pPD  (Node  C  local  RMdatapool)  and  MFT34DPD  (Node  C7  local 

datapool)  have  had  significant  reductions  to  available  space  and  currently  have  extremely 
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limited  spare  capacity.  Due  to  the  functionality  of  the  C  Nodes  and  the  expected  future 
expansions  to  this  functionahty,  this  is  an  area  of  concern. 

n  1  Local),  MFr42DPD  fD3/D4  Local),  and  MFT45DPD  (Node 

D  local  RM  datapool)  have  also  experienced  significant  growth. 

It  should  also  be  noted  that  available  datapool  space  is  a  function  of  the  datapool  uartition  n. 
defined  in  the  S  YSGEN.  TSSA  has  accomplished  some  restructuring  of  the  SYSGEN 
partitions  before  (addition  of  a  C7  overlay  task  during  the  D01/D02  effort),  but  this  is 
currently  a  little  understood/documented  area  that  requires  further  smdy  to  determine  the 
true  allowable  spare  memory. 


5.5.3 


Frame  Time 


Frame  time  measurements  are  taken  from  contractor  developed  utilities.  Frame  time 

measurements  are  mn  against  a  standard  pre-defined  max  threat  scenario  Due  to  the  hieh 

imount  of  vanation  in  frame  time  measurements  (pre-DOl  baselines  showed  a  standard 

deviation  in  measurement  of  over  15  percent)  averages  from  several  baselines  are  presented 

here,  i.e.,  an  average  ot  five  baselines  from  7/92  to  5/93  comprises  the  Pre-DOl  avera^^e 
measurements.  avcia^c 


Node 

Pre-DOl  Avg 

DOl  Av^ 

D02  .\vf» 

%  change 

A1 

36 

(from  Prp.nni) 

39 

38 

-7.08 

A2 

54 

60 

64 

-18.96 

A3 

68 

56 

48 

29.13 

Bl 

35 

38 

38 

-8.57 

B2 

63 

62 

62 

1.90 

B3 

36 

46 

43 

-18.52 

B4 

58 

68 

61 

-5.75 

B5 

61 

64 

65 

-6.21 

B6 

76 

80 

80 

-4.99 

Cl 

56 

55 

49 

13.71 

C2 

33 

71 

85 

-159.15 

C3 

78 

93 

90 

-15.22 

C4 

80 

40 

29 

64.17 

C5 

41 

52 

48 

-15.14 

C6 

69 

90 

76 

-9.34 

Cl 

62 

63 

46 

26.05 

D1 

60 

74 

57 

4.76 

D2 

70 

83 

63 

10.22 

D3 

73 

92 

82 

-12.18 

D4 

92 

100 

97 

-5.30 

D5 

49 

68 

29 

40.62 

D6 

59 

83 

64 

-8.11 

average 

59.59 

67.15 

59.70 

-4.73 

Table  J 

Percentage  Spare  Frame  Time 

From  the  data  presented  here,  the  accuracy  ot  the  current  frame  time  measurement 
technique  can  be  questioned.  This  would  certainly  appear  to  be  an  area  that  requires  further 


14 


D01/D02  Design  Report 


Rev:  Oris 
Julv  5.  1996 


5.5.4  I/O  Channel  Utilization 

No  effort  is  currently  made  to  analyze  or  capture  I/O  bandwidth  and  I/O  frame  timins  data. 
5.6  Schedule 

Final  delivery  schedules,  anticipated  and  actual,  are  TBD. 

Subbuild  information  for  both  DOl  and  D02  baselines  is  available  but  has  not  been  included 
in  this  report.  It  should  be  noted  however,  that  approximately  19  subbuilds  were 
incorporated  into  the  DOl  baseline,  and  17  into  D02. 
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6.0  Conclusions 

The  purpose  of  this  report  is  twofold;  to  present  historical  information  on  the  D01/D02 
baselines  and  their  impact  on  the  F-14D  training  devices,  and  to  provide  a  guideline  for  the 
future  software  developments  on  those  baselines. 

It  is  felt  that  this  repon  provides  adequate  information  in  some  areas,  and  points  to  other 
areas  where  data  is  needed.  In  some  cases  the  needed  data  is  available  but  not  in  a  readily 
accessible  format,  in  other  cases  the  information  is  not  collected. 
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A.XARD1P 
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F.MFRMIF 
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F.XFRCFG 
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M1A1.D 

J.CLDSTT 

M1A3.D 

J.COMP 

M1B1.D 

J.COPY 

M1B3.D 

J.CTA3 

M1C1.D 

J.C7T6MG 
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Appendix  A 

F-14D01  Designs  and  Associated  TIniK 

FY93/F14D01-01.02 

_ Sensor  Control  MechaniTatinn  /41 

FilGs) 

A.XARD1P 

F.SRLVID 

F.SRTWS 

I.SRLTGT 

A.XARD1U 

F.SRMRL 

F.SRVSL 

I.SRLVID 

A.XDCE1C 

F.SRMSL 

F.SSSP 

I.SRMRL 

A.XSDS1P 

F.SRPAL 

F.STCLOS 

I.SRMSL 

A.XSDS1U 

F.SRPDS 

F.STMODE 

I.SRPAL 

F.SRAGR 

F.SRPDST 

F.XABIRT 

I.SRPDS 

F.SRDDP 

F.SRPLM 

I.SRAGR 

I.SRPDST 

F.SRGM 

F.SRPS 

I.SRDDP 

I.SRPLM 

F.SRHTGT 

F.SRPSTT 

I.SRGM 

I.SRPS 

F.SRHVID 

F.SRRWS 

I.SRHTGT 

I.SRPSTT 

F.SRLTGT 

F.SRSIF 

I.SRHVID 

I.SRRWS 

FY93/F14D01-01.04 

JTIDS  FiQhter-To-FinhtPr  Datal  ink 

(41  Fil 

A.DSSINI 

D.OSWDFM 

F.OJTDS1 

.  I.OACNTL 

A.XBIU2B 

D.OSWDFW 

F.OJTDS2 

I.OCLASS 

A.XDSS2P 

D.XSTB3M 

F.OJTDS3 

I.CXLOCK 

A.XDSS2U 

D.XSTB3W 

F.OJTDS4 

I.ODATL2 

A.XJTD2P 

F.OACNTL 

F.ONLSW 

I.ODATLK 

A.XJTD2U 

F.OCUSS 

F.OTAC2D 

I.OJTDS1 

D.ODS5M 

F.OCLOCK 

F.OTMACD 

I.OJTDS2 

D.ODS5T 

F.ODATL2 

F.VCIU1 

I.OJTDS3 

D.ODS5W 

F.ODATLK 

F.XABIRT 

I.OJTDS4 

FY93/F14001-01.0.S 

ORT  Abort 

(10  Files) 

F.SRCM 

F.SRORT 

F.SRTRAN 

I.SRDDS 

F.SRDDS 

F.SRTMDS 

I.SRCM 

I.SRORT 

PY93/F^ *^001  -01  ■Q7 _ Screen  Target  DesinnatP  (10  Files) 


F.SROBSF 

F.SRTDEL 


F.SRTFMT 

F.SRTTFS 


G.SRTTCG 

G.SRTTFG 


I.SROBSF 

I.SRTDEL 


FY93/F1 4001 -01 .03  Flexible  Missile  Messanps 


(21  Files) 


A.XARD1P 

A.XARDCP 

F.SDDETir 

F.SRCME 

F.SRJVFD 


F.SRJVGP 

F.SRMFK 

F.SRPDST 

F.SRTDEL 

F.SRTFMT 


F. SRTTFS 

G. SRTTFG 
I.SDDENT 
I.SRCME 
I.SRJVFD 


I.SRJVGP 

I.SRMFK 

I.SRPDST 

I.SRTDEL 

I.SRTFMT 


Rev.  Oris 
July  5.  1996 


I.SRSIF 

I.SRTWS 

I.SRVSL 

I.SSSP 

I.STCLOS 

I.STMODE 

I.XABIRT 


I.ONLSW 

I.OTAC2D 

I.OTMACD 

I.VCIU1 

I.XABIRT 


I.SRTMDS 

I.SRTRAN 


I.SRTFMT 

I.SRTTFS 


I.SRTTFS 
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FY93/F14DQ1 -01 .1 2  RWS  Moria  Uoamfip  (60  Files) 


F.OAWPN1 

F.SRJRD 

F.SRTMDS 

F.OPILOT 

F.SRJRPT 

F.SRTOFS 

F.ORIO 

F.SRJVFD 

F.SRTRAN 

F.OTACPM 

F.SRJVGP 

F.SRTTD 

F.SRCURS 

F.SRMFK 

-F,SRVID 

F.SRDDBS 

F.SRMFKS 

F.SRXMIT 

F.SRDDS 

F.SRMODE 

I.OAWPN1 

F.SRHDEr 

F.SROBSF 

I.OPILOT 

F.SRJCGS 

F.SROTC 

I.ORIO 

F.SRJCO 

F.SRPDST 

I.OTACPM 

F.SRJMFR 

F.SRTBIT 

I.SRCURS 

F.SRJPRN 

F.SRTIDS 

I.SRDDBS 

FY93/F14noi-ni 

.13 

HRWS  Default  Scan  Selertinn  lo 

F.SRRWS 

I.SRRWS 

FY93/F14Dni.ni  1A 

_ AIM*7M  Second  Missile  MpQcano 

F.VOWRR 

I.VRDRML 

F.OMSLSC 

F.VRDRML 

I.VWPNLD 

F.OPMWPN 

F.VWPNLD 

I.WLDMSL 

F.OPRSET 

F.WLDMSL 

I.WMFLY 

F.OTMWPN 

F.WMFLY 

F.M05V4101.F 

F.OWPCAP 

I.VOWFIR 

F.OLMPRS 

F.SRMSL 

FY93/F14D01-01 

.17 

Radiation  Modes  fRPP\  mr 

D.XSTC7M 

F.SRNCTR 

F.SRTDFS 

D.XSTC7W 

F.SRRAM 

F.SRXMIT 

F.SRDDP 

F.SRRRE 

I.SRDDP 

F.SRDFDT 

F.SRTDEL 

I.SRDFDT 

FY93/F14D01-ni 

Snip  Arrow 

Limitation  ta  P!Ioc\ 

A.XARD1U 

F.SRTIDS 

G.SRTIDG 

F.NINS 

FY93/Fi4nni-ni 

12_ 

HUDCaae/Uncanp  lo 

F3(DCEWR 

I.XDCEWR 

FY93/F14D01-01  21 

—Flight  Director  Mode  (O 

F.XDCEC5 

I.XDCEC5 

I.SRDDS 

I.SRHDET 

I.SRJCGS 

I.SRJCO 

I.SRJMFR 

I.SRJPRN 

i.SRJRD 

I.SRJRPT 

I.SRJVFD 

I.SRJVGP 

I.SRMFK 

I.SRMFKS 


Files) 


(26  Files) 

M05V4101.F 

I.OLMPRS 

I.OMSLSC 

I.OPMWPN 

I.OPRSET 

I.OTMWPN 


I.SRNCTR 

I.SRRAM 

I.SRRRE 

I.SRTDEL 


I.NINS 


I.SRMODE 

I.SROBSF 

I.SROTC 

I.SRPDST 

I.SRTBIT 

I.SRTIDS 

I.SRTMDS 

I.SRTOFS 

I.SRTRAN 

I.SRTTD 

I.SRVID 

I.SRXMIT 


I.OWPCAP 

I.SRMSL 


I.SRTDFS 

I.SRXMIT 


I.SRTIDS 
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(31  Files’) 


EMIT.* 

F.ERDPLY 

F.OACTON 

I.ERBIT3 

I.MACT2 

F.C1CS1 

F.EFEXEC 

F.QF14A 

I.ERDPLY 

I.OACTON 

F.CICS1 

F.ERINIT 

I.CICS1 

I.EREXEC 

I.QF14A 

F.ERAUD 

F.EROFF 

I.CICS1 

I.ER1NIT 

F.ERBIT1 

F.ERTES 

iERAUD 

I.EROFF 

F.ERBIT2 

F.ERTRCK 

I.ERBIT1 

I.ERTES 

F.ERBIT3 

F.MACT2 

I.ERBIT2 

I.ERTRCK 

’Note:  An  indeterminant  number  of  emitter  files  were  updated  with  this  design  and  are 
denoted  by  EMIT.*  files  in  the  tactical  directory. 


(180  Files) 


A.XB1U1B 

A.XIRS1P 

A.XIRS1U 

D.XSTC1M 

D.XSTC1W 

D.XSTC3M 

DJ<STC3W 

D.XSTC4M 

D.XSTC4W 

F.DHBTWE 

F.DHBWEA 

F.OAWPN1 

F.OTMWPN 

F.OVISCN 

F.SIASID 

F.SIBPNT 

F.SIC1B 

F.SIC1TG 

F.SIC2B 

F.SIC4B 

F.SICFD 

F.SICHNR 

F.SICOOL 

F.SIDET 

F.SIDETI 

F.SIDETP 

F.SIDETS 

F.SIDISC 

F.SIFOV 

F.SIGIMB 

F.SIHTGT 

F.SIHTIR 

F.SILMOD 


F.SIMSGC 

F.SIMSGH 

F.SIMSGT 

F.SINSSM 

F.SINTWM 

F.SIOSD 

F.SIPAL 

F.SlPDAA 

F.SlPDAT 

F.SlPDCB 

F.SlPDCI 

F.SlPDCP 

F.SlPDCR 

F.SlPDCT 

F.SlPDDG 

F.SlPDDM 

F.SiPDDP 

F.SlPDEA 

F.SlPDRM 

F.SlPDRN 

F.SlPDRV 

F.SlPDSA 

F.SIPDSC 

F.SIPDSR 

F.SlPDST 

F.SIPDTA 

F.SIPLM 

F.SIPODC 

F.SIPODD 

F.SIPTL 

F.SIPTLG 

F.SIPTLl 

F.SIRACDM 


F.SIRTC 

F.SIRTI 

F.SIRTRAN 

F.SISAM 

F.SISCAN 

F.SISCNC 

F.SISOUT 

F.SISTT 

F.SISTTP 

F.SISYSI 

F.smsT 

F.SITACT 

F.SITRKF 

F.SfTRKH 

F.SITWSA 

F.SITWSM 

F.SRDDS 

F.SRSIF 

F.XDPVS1 

F.XINICI 

F. XVSAD1 

G. SRMFKG 
G.SRSYMG 
aSHTIDG 
I.DHBTWE 
I.DHBWEA 
I.OAWPN1 
I.OTMWPN 

I.OVISCN 

I.SIASID 

I.SIBPNT 

I.SIC1B 

I.SIC1TG 


I.SICHNR 

I.SICOOL 

I.SIDET 

I.SIDETI 

I.SIDETP 

I.SIDETS 

I.SIDISC 

I.SIFOV 

I.SIGIMB 

I.SIHTGT 

I.SIHTIR 

I.SILMOO 

I.SIMRG 

I.SIMRGR 

I.SIMSG 

I.SIMSGC 

I.SIMSGH 

I.SIMSGT 

I.SINSSM 

I.SINTWM 

I.SIOSD 

I.SIPAL 

I.SlPDAA 

I.SlPDAT 

I.SIPDCB 

I.SlPDCI 

I.SlPDCP 

I.SlPDCR 

I.SlPDCT 

I.S1PDDG 

I.SlPDDM 

I.SlPDDP 

I.SlPDEA 


I.SlPDSA 

I.SlPDSC 

I.SlPDSR 

I.SlPDST 

I.SlPDTA 

I.SIPLM 

I.SIPODC 

I.SIPODD 

I.SIPTL 

I.SIPTLG 

I.SIPTLl 

I.SIRACDM 

I.SIRBACK 

I.SIRCLUT 

I.SIRPATH 

I.SIRTC 

I.SIRTI 

I.SIRTRAN 

I.SISAM 

I.SISCAN 

I.SISCNC 

I.SISOUT 

I.SISTT 

I.SISTTP 

I.SISYSI 

I.SIT1ST 

I.SITACT 

I.SITRKF 

I.SITRKH 

I.SITWSA 

I.SITWSM 

I.SRODS 

I.SRSIF 
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FY93/F14D01-01 .28  Infrared  Search  and  Track  HRST’i  (continued) 


F.SIMRG 

F.SIRBACK 

I.SIC2B 

I.SIPDRM 

I.XDPVS1 

F.SIMRGR 

F.SIRCLUT 

I.SIC4B 

I.SIPDRN 

I.XINICI 

F.SIMSG 

F.SIRPATH 

I.SICFD 

I.SlPDRV 

I.XVSAD1 

FY93/F14D01-01.32  Multiplex  Bus  Messages  (2  Files) 


A.XARD1P 

FY93/F14D01-03 

A.XARDCP 

_ OBOGS  C/A  Light  Illumination 

(8  Files) 

I.OMBLKD 

and  Unknown 

I.ONRLTS 

(116  Files) 

F.ALTCWP 

F.ALTCWR 

FY93/F14D01-XXX  _ 

F.OMBLKD 

F.ONRLTS 

DR  Corrections. 

I.ALTCWP 

I.ALTCWR 

Miscellaneous. 

A.XARD1P 

F.SRPSTT 

F.SSSP 

‘  I.SRPDST 

I.SSCU 

A.XAR01U 

F.SRRRE 

F.STCLOS 

I.SRPSTT 

I.SSSP 

A.XARDCP 

F.SRRWS 

F.VC1U1 

I.SRRRE 

I.STCLOS 

A.XSDS1P 

F.SRTDBS 

F.XFHIFC 

I.SRRWS 

I.VCIU1 

D.XSTC7M 

F.SRTDFS 

G.SRMFKG 

I.SRTDBS 

I.XFHIFC 

DJ<STC7W 

F.SRTDHF 

G.SRSYMG 

I.SRTDFS 

F.FSP42G 

F.GETREC 

F.SR7DRO 

G.SRnDG 

I.SRTDHF 

F.MPRSW3 

F.RADAGE 

F.SRTDUL 

I.GETREC 

I.SRTDRO 

F.CX^VREC 

F.SDBLNK 

F.SRTDUR 

I.RADAGE 

I.SRTDUL 

F.SRINIT 

F.SDDENT 

F.SRTFDT 

I.SDBLNK 

I.SRTDUR 

F.SRRFDP 

F.SIDISC 

F.SRTFMT 

I.SDDENT 

I.SRTFDT 

F.SRWRAS 

F.SRANTC 

F.SRTIDS 

I.SIDISC 

I.SRTFMT 

G.SRCDTG 

F.SRCDTS 

F.SRTIRS 

I.SRANTC 

I.SRTIDS 

G.SRTDFG 

F.SRCURS 

F.SRTMDS 

I.SRCDTS 

I.SRTIRS 

G.SRTWPG 

F.SRDATA 

F.SR7TJGS 

I.SRCURS 

I.SRTMDS 

I.FSP42G 

F.SRDDBS 

F.SRTOFS 

I.SRDATA 

I.SRTNGS 

I.MPRSW3 

F.SRDDP 

F.SRTRAN 

I.SRDDBS 

I.SRTOFS 

I.OCVREC 

F.SRDDS 

F.SRTTCS 

I.SRDDP 

I.SRTRAN 

I.SRINIT 

F.SRDFDT 

F.SRTTFS 

1.SRDDS 

I.SRTTCS 

I.SRRFDP 

F.SRDIRS 

F.SRTWPS 

I.SRDFDT 

I.SRTTFS 

I.SRWRAS 

F.SRIC 

F.SRTWS 

I.SRDIRS 

I.SRTWPS 

F.SRLARC 

F.SRVID 

I.SRIC 

I.SRTWS 

F.SRMFKS 

F.SRXMIT 

I.SRLARC 

I.SRVID 

F.SRPDST 

F.SSCU 

I.SRMFKS 

I.SRXMIT 
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f^Y.95/F-^4QQ2-001 - lactical  Tape  OroP-ln  (RT  Incomoratloni  (30  Files) 


A.XADA2P 

A.XARD1P 

A.XARD1U 

A.XARD2P 

A.XARD2U 

A.XARDCP 


A.XBIU2B 

A.XCIU2P 

A.X1NS2P 

A.XINS2U 

A.XIRS1P 

A.XSDS1P 


A.XSMS2P 

D.DP1CFG 

D.DP2CFG 

D.MC1CFG 

P,MC2CFG 

F.SRPDS 


F.SRPDST 

F.SRPS 

F.SRPSTT 

F.SRSIF 

F.XABIRT 

I.SRPDS 


1.SRPDST 

I.SRPS 

I.SRPSTT 

I.SRSIF 

I.XABIRT 

M.I.VSA02 


FY9?/'F-''4PQg-?<xx _ System  Expansion  (SYSGEN  RM  nr  np> 


(41  Files) 


D.MFTOO 

D.MFT45 

F.SRTDHF 

I.SRU^RC 

M.I.VSA02 

D.MFT11 

D.MFT51 

F.SRTIRS 

I.SRTDBS 

M1C3.D 

D.MFT20 

D.MFT52 

F.SRTMDS 

I.SRTDHF 

M1C7.D 

D.MFT22 

D.MFT90 

F.SRTNGS 

I.SRTIRS 

W1C3.D 

D.MFT30 

D.WSTOO 

F.SRTOFS 

I.SRTMDS 

W1C7.D 

D.MFT31 

F.GETREC 

F.SRTTCS 

.  I.SRTNGS 

D.MFT34 

F.RADAGE 

F.SRTWPS 

I.SRTOFS 

D.MFT40 

F.SRLARC 

I.GETREC 

I.SRTTCS 

D.MFT42 

F.SRTDBS 

I.RADAGE 

I.SRTWPS 

FY95/F-I4DQ2-X?<?< - ISSA  Development  Fnvironment  (Ot  Files) 


CO 

J.BASELMPX 

J.CLEANALL 

J.COMP 

J.SMTINSTALL 

D.ODSEDT 

J.BASELSCT 

J.CLEANDPD 

J.COPY 

J.TSSA 

J.BACKUP 

J.BASELTSK 

J.CLEANIOS 

J.DPD 

MKSDTF 

J.BASELALL 

J.BLDCTM 

J.CLEANMAC 

J.GPL 

J.BASELDPD 

J.BLDCTW 

J.CLEANMPX 

J.IPRBG 

J.BASELIOS 

J.CAT 

J.CLEANSCT 

J.MAC 

J.BASELMAC 

J.CATW 

J.CLEANTSK 

J.RESTORE 

F2!^.5/.F_-.1  4002-01 

.01  MPRF  M4B 

Files) 

D.ONLDAT 

F.SRJCRS 

F.SRRWS 

I.SRCDTS 

I.SRMTGT 

D.ONRDAT 

F.SRJMFR 

F.SRSIF 

I.SRCME 

I.SRNCTR 

D.OSWDFM 

F.SRJN 

F.SRTFMT 

I.SRCURS 

I.SROBSF 

D.OSWDFW 

F.SRJPRN 

F.SRTIDS 

I.SRDATA 

I.SROTC 

F.ERTCS 

F.SRJPT 

F.SRTOFS 

I.SRDDP 

I.SRPAL 

F.MPRSW3 

F.SRJRD 

F.SRTRAN 

I.SRDDS 

I.SRPDS 

F.MPRSW4 

F.SRJRGP 

F.SRTSIG 

I.SRFLYC 

I.SRPDST 

F.OAWPN1 

F.SRJVFD 

F.SRTWS 

I.SRGM 

I.SRPLM 

F.OMBLKD 

F.SRJVGP 

F.SRVID 

I.SRHVID 

I.SRPS 

F.ONRS01 

F.SRLVID 

F.SRVSL 

I.SRIFFV 

I.SRPSTT 

F.OPILOT 

F.SRMDET 

F.SRXFER 

I.SRINIT 

I.SRRAM 

F.ORIO 

F.SRMDI 

F.SRXMIT 

I.SRJCGS 

I.SRRGP 

F.OTACPM 

F.SRMFK 

F.SSSP 

I.SRJCO 

I.SRRGST 

F.OTMWPN 

F.SRMFKS 

F.YGPOVY 

I.SRJCRS 

I.SRRWS 
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FY_9_5/F- 14002-0 1,01 

_  MPRF  (continued) 

F.SDDENT 

F.SRMODE 

F.YINSCN 

I.SRJMFR 

F.SRACQF 

F.SRMRL 

G.SRCDTG 

I.SRJN 

F.SRANTC 

F.SRMSL 

G.SRTMDG 

I.SRJPRN 

F.SRCDTS 

F.SRMTGT 

I.ERTES 

I.SRJPT 

F.SRCME 

F.SRNCTR 

I.MPRSW3 

I.SRJRD 

F.SRCURS 

F.SROBSF 

I.MPRSW4 

I.SRJRGP 

F.SRDATA 

F.SROTC 

I.OAWPN1 

I.SRJVFD 

F.SRDDP 

F.SRPAL 

I.OMBLKD 

I.SRJVGP 

F.SRDDS 

F.SRPDS 

I.ONRS01 

I.SRLVID 

F.SRFLYC 

F.SRPDST 

I.OPILOT 

I.SRMDET 

F.SRGM 

F.SRPLM 

I.ORIO 

I.SRMDI 

F.SRHVID 

F.SRPS 

I.OTACPM 

I.SRMFK 

F.SRIFFV 

F.SRPSTT 

I.OTMWPN 

I.SRMFKS 

F.SRINIT 

F.SRRAM 

I.SDDENT 

I.SRMODE 

F.SRJCGS 

F.SRRGP 

I.SRACQF 

.  I.SRMRL 

F.SRJCO 

F.SRRGST 

I.SRANTC 

I.SRMSL 

FY95/F-14D02-01.02 

PW  (26  Files) 

F.OPILOT 

F.SRPVU 

F.SRVID 

I.SRMODE 

F.ORIO 

F.SRTDRO 

I.OPILOT 

I.SRPVU 

F.OTACPM 

F.SRTDUL 

I.ORIO 

I.SRTDRO 

F.OTMWPN 

F.SRTDUR 

I.OTACPM 

I.SRTDUL 

F.SRDDS 

F.SRTIDS 

I.OTMWPN 

I.SRTDUR 

F.SRMODE 

F.SRTRAN 

I.SRDDS 

I.SRTIDS 

FY.95/F-14D.Q2-01 .03  Air-To-Gmiinri  (132  Files) 


A.XSMS2P 

F.VARMW 

F.WPAAI2 

I.SREOP 

A.XSMS2U 

F.VASSEL 

F.WPAAI3 

I.SRJRGP 

D.XSTD3M 

F.VBMREL 

F.WRDQUE 

I.SRRRE 

D.XSTD3W 

F.VCLRW 

F.WRLPSN 

I.TSP30X 

F.AAIL14 

F.VCONF1 

F.WSLOT 

I.VARMW 

F.CURVFT 

F.VCONF2 

F.WTRMHT 

l.VASSEL 

F.DPCWPS 

F.VEMJET 

F.XABIRT 

I.VBMREL 

F.FWTBD1 

F.VEVNTS 

F.XCRASH 

I.VCLRW 

F.FWTBL1 

F.VGNFIR 

I.AAIL14 

I.VCONF1 

F.OERDAT 

F.VPBIT 

I.CURVFT 

I.VCONF2 

F.OLMPRS 

F.VPWRST 

I.DPCWPS 

I.VEMJET 

F.OMBLKD 

F.VRDRML 

I.FWTBD1 

I.VEVNTS 

F.OMMENU 

F.VSMJET 

I.FWTBL1 

I.VGNFIR 

F.OMSMAC 

F.VSMOFF 

I.OERDAT 

I.VPBIT 

F.OPILOT 

F.VSMSEX 

I.OLMPRS 

I.VPWRST 

F.OPILT2 

F.VSMSl 

I.OMBLKD 

I.VRDRML 

F.OPLS01 

F.VSMTAC 

I.OMMENU 

I.VSMJET 

I.SRSIF 

I.SRTFMT 

I.SRTIDS 

I.SRTOFS 

I.SRTRAN 

I.SRTSIG 

I.SRTWS 

I.SRVID 

I.SRVSL 

I.SRXFER 

I.SRXMIT 

I.SSSP 

I.YGPOVY 

I.YINSCN 


I.SRTRAN 

I.SRVID 


I.WIMPAC 

I.WINIT1 

I.WLDBMB 

I.WPAAI1 

I.WPAAI2 

I.WPAAI3 

I.WRDQUE 

I.WRLPSN 

I.WSLOT 

I.WTRMHT 

I.XABIRT 

I.XCRASH 
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FY95/F-14D02-Q1.Q3 

Air-To-Ground  (continued) 

F.OPMWPN 

F.VSRSEL 

I.OMSMAC 

I.VSMOFF 

F.OPRSET 

F.VSWL 

I.OPILOT 

I.VSMSEX 

F.OSTAT 

F.VWINV 

I.OPILT2 

I.VSMSI 

F.OTMWPN 

F.VWPNLD 

LOPLSOI 

I.VSMTAC 

F.OWYPTC 

F.W14EXC 

I.OPMWPN 

I.VSRSEL 

F.PINST1 

F.WBFLY 

I.OPRSET 

I.VSWL 

F.SFIAGR 

F.WBOMB 

I.OSTAT 

I.VWINV 

F.SRANTC 

F.WF14DM 

I.OTMWPN 

I.VWPNLD 

F.SRDIRS 

F.WFMU 

I.OWYPTC 

I.W14EXC  . 

F.SREOP 

F.WIMPAC 

I.PINST1 

I.WBFLY 

F.SRJRGP 

F.WINIT1 

I.SRAGR 

I.WBOMB 

F.SRRRE 

F.WLDBMB 

I.SRANTC 

I.WF14DM 

F.TSP30X 

F.WPAAI1 

I.SRDIRS 

I.WFMU 

FY95/F-14O02-Q1. 

11 

JTIDS  (35 

Files) 

A.XJTD2P 

F.RADAGE 

F.SRTTFS 

I.OEWJAM 

I.SRDFDT 

F.OACNTL 

F.SDBLNK 

F.SRTWPS 

I.OJTDS1 

I.SRJTDR 

F.OEWJAM 

F.SRDFDT 

G.SRTDFG 

I.OJTDS3 

I.SRJTID 

F.OJTDS1 

F.SFUTDR 

G.SRT1DG 

I.OJTDS4 

I.SRTDFS 

F.OJTDS3 

F.SFUTID 

G.SRTTFG 

I.OWYPTC 

I.SRTIDS 

F.OJTDS4 

F.SRTDFS 

G.SRTWPG 

I.RADAGE 

I.SRTTFS 

F.OWYPTC 

F.SRTIDS 

I.OACNTL 

I.SDBLNK 

I.SRTWPS 

FY95/F- 14002-01. 

,27 

MC/AROP 

1553  Interface 

(1  File) 

A.XARD2P 

FY95/F-14D02-03 

SDIS  (24  Files) 

A.XSDS1P 

F.ONLS01 

F.SRPS 

I.ONLS01 

I.SRPS 

D.ONLDAT 

F.ONLSW 

F.SRRWS 

I.ONLSW 

I.SRRWS 

D.OSWDFM 

F.ONRS01 

F.SSCU 

I.ONRS01 

I.SSCU 

D.OSWDFW 

F.ORDSWD 

F.SSSP 

I.ORDSWD 

I.SSSP 

F.ONLLTS 

F.SRPDS 

I.ONLLTS 

I.SRPDS 

FY95/F- 14002-06 

Engine  Mode  Select  Functir^n 

(2  Files) 

F.PENGCS 

I.PENGCS 
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FY95/F-14DQ2-XXX 

IRST/VSC 

(184  Files) 

D.XSTC3M 

F.SILMOD 

F.SIRBACK 

I.SIE5HZA 

I.SlPDEA 

D.XSTC3W 

F.SIMRG 

F.SIRPATH 

I.SIE5HZB 

I.SlPDRM 

D.XSTC4M 

F.SIMRGR 

F.SIRTC 

I.SIE5HZC 

I.SIPORN 

D.XSTC4W 

F.SIMSG 

_F.SIRTI 

I.SIEBLKD 

I.SlPDRV 

F.SIASID 

F.SIMSGC 

F.SIRTRAN 

I.SIEEND 

I.SlPDSA 

F.SIBPNT 

F.SIMSGH 

F.SISAM 

I.SIEENV 

I.SlPDSC 

F.SIC1B 

F.SIMSGT 

F.SISCAN 

I.SIEISM 

I.SlPDSR 

F.S1C1TG 

F.SINSSM 

F.SISCNC 

I.SIESET 

I.SIPDST 

F.SIC2B 

F.SINTWM 

F.SISIMG 

I.SIFOV 

I.SIPDTA 

F.SIC4B 

F.SIOSD 

F.SISOUT 

I.SIGIMB 

I.SIPLM 

F.SICALC 

F.SIPAL 

F.SISTT 

I.SIHTGT 

I.SIPODC 

F.SICFD 

F.SIPCLUT 

F.SISTTP 

I.SIHTIR 

I.SIPODD 

F.S1CHNR 

F.SlPDAA 

F.SISYSI 

I.SIISCZ 

I.SIPTL 

RSIODOL 

F.SlPDAT 

F.SIT1ST 

•  I.SIISPT 

I.SIPTLG 

F.S1DET 

F.SlPDCB 

F.SITACT 

I.SIISZA 

I.SIPTLI 

F.SIDETI 

F.SlPDCP 

F.SITRKF 

I.SIISZE 

I.SIRACDM 

F.SIDETP 

F.SlPDCR 

F.SITRKH 

I.SILMOD 

I.SIRBACK 

F-SIDETS 

F.SlPDCT 

F.SITWSA 

I.SIMRG 

I.SIRPATH 

F.SIDISC 

F.SIPDDG 

F.srrwsM 

I.SIMRGR 

I.SIRTC 

F.SIE1HZA 

F.SIPDDM 

FXIOSGC 

I.SIMSG 

I.SIRTI 

F.SIE1HZB 

F.SlPDDP 

I.SIASID 

I.SIMSGC 

I.SIRTRAN 

F.SIE5HZA 

F.SlPDEA 

I.SIBPNT 

I.SIMSGH 

I.SISAM 

F.SIE5HZB 

F.SlPDRM 

I.SIC1B 

I.SIMSGT 

I.SISCAN 

FSIESHZC 

F.SlPDRN 

I.SIC1TG 

I.SINSSM 

I.SISCNC 

FSIEBLKD 

F.SlPDRV 

I.SIC2B 

I.SINTWM 

I.SISIMG 

FSIEB^D 

F.SlPDSA 

I.SIC4B 

I.SIOSD 

I.SISOUT 

F.SIEENV 

F.SlPDSC 

I.SICALC 

I.SIPAL 

I.SISTT 

F.StEISM 

F.SlPDSR 

I.SICFD 

I.SIPCLUT 

I.SISTTP 

F.SIESET 

F.SlPDST 

I.SICHNR 

I.SlPDAA 

I.SISYSI 

F.SIFOV 

F.SlPDTA 

I.SICOOL 

.  I.SlPDAT 

I.SIT1ST 

F.SIGIMB 

F.SIPLM 

I.SIDET 

*  I.SlPDCB 

I.SITACT 

F.SIHTGT 

F.SIPODC 

I.SIDETI 

I.SlPDCP 

I.SITRKF 

F.SIHTIR 

F.SIPODD 

I.SIDETP 

I.SlPDCR 

i.srrRKH 

F.SIISCZ 

F.SIPTL 

I.SIDETS 

I.SlPDCT 

I.SITWSA 

F.SIISPT 

F.SIPTLG 

I.SIDISC 

I.SlPDDG 

I.SITWSM 

F.S1IS2A 

F.SIPTLl 

I.SIE1HZA 

I.SlPDDM 

I.XIOSGC 

F.SI1SZE 

F.SIRACDM 

I.SIE1HZB 

I.SlPDDP 
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FY.9.5/F...14D02-XXX 

_ Unknown  OR  Correotinnf; 

(60  Files) 

F.BFNDT 

F.OAFLD2 

F.VSMSEX 

I.MKULST 

I.OGCATS 

F.EXPDSN 

F.OAFLIB 

F.XAB1VS 

I.MTSIOC 

I.OMALTR 

F.IMPDSN 

F.OAFRMP 

F.XEMPPi' 

I.OAFADD 

I.PRPLD 

F.KILRAS 

F.OAFTO 

_F,XSPIF 

I.OAFCN2 

I.SRJTDR 

F.MIOSKB 

F.OAFWT2 

F.YGPACT 

I.OAFDEF 

I.SRTIDS 

F.MKBIOC 

F.OAFWTM 

aSRIlDG 

I.OAFGEN 

I.SRTIRS 

F.MKULST 

F.OGCATS 

I.BFNDT 

I.OAFLD2 

I.VSMSEX 

F.MTSIOC 

F.OMALTR 

I.EXPDSN 

I.OAFLIB 

I.XAB1VS 

F.OAFADD 

F.PRPLD 

I.IMPDSN 

I.OAFRMP 

I.XEMPTY 

F.OAFCN2 

F.SFUTDR 

I.KILRAS 

I.OAFTO 

I.XSPIF 

F.OAFDEF 

F.SRTIDS 

l.MIOSKB 

I.OAFWT2 

I.YGPACT 

F.OAFGEN 

F.SRTIRS 

I.MKBIOC 

I.OAFWTH 

M.I.VSA02 

FY95/F-14O02-XXX 

Unknown 

(29  Files) 

. 

F.OCVREC 

F.SRHTGT 

F.SRTTD 

I.SDDCAK 

I.SRRFDP 

F.ONLBEM 

F.SRJRPT 

F.STCLOS 

I.SRDETR 

I.SRSCNV 

F.ONRBEM 

F.SRLTGT 

G.SRMFKG 

ISRHOET 

I.SRTIDP 

F.SDDCAK 

F.SRRFDP 

I.OCVREC 

I.SRHTGT 

I.SRTTD 

F.SRDETR 

F.SRSCNV 

I.ONLBEM 

I.SRJRPT 

I.STCLOS 

F.SRHDEr 

F.SRTIDP 

I.ONRBEM 

I.SRLTGT 

Note;  Units  in  Italics  are  units  that  were  original  to  the  baseline  (new  units). 


Appendix  B 
Page  5  of  5 


APPENDIX  I 


WRA  LOAD  STATION 
OPERATION  MANUAL 
(Excerpts) 


WRA  Load  Station 

Operations  Manual 


P/N  A55U70006 


CONTENTS 


1  INTRODUCTION  . 

2  OPERATIONAL  ENVIRONMENT 

2.2  PROGRAM  MATERIALS  . 

2.3.  SUPPORTING  DOCUMENTATION  . 

3  SETUP  . 

3.1  PC  . 

3.2  LVTS/DMLV  . 

3.3  WRA  . 

4  MENU  OPERATIONS  . 

®4.1  LOAD  W/AUTO  VERIFY . 

4.2  VERIFY . 

4.3  SAVE  . 

4.4  DISPLAY  LIBRARY . 

4.5  DELETE  FILE . 

4.6  DISK  OPERATIONS . 

4.6.1  BACKUP  WRA  FILE  TO  DISK  . 

4.6.2  RESTORE  WRA  FILE(S)  FROM  DISK 

4.6.3  FORMAT  FLOPPY  DISK . 

4.7  SHUTDOWN  . 

5  ERROR  MESSAGES  . 
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INTRODUCTION 


2.3.1 


2.3.2 


This  Operation  Manual  describes  the  procedures  necessarv  fnr  «««  *  . 
initiate,  operate  and  monitor  the  WRA  Loaa  Station,  ^  Operator  to 

OPERATIONAL  ENVIRONMENT 

ENVIRONMENTAL  RANGE 

Temperature;  41  to  90  degrees  F  (5  to  32  degrees  C)  operating 
PROGRAM  MATERIALS 

5  1/4  inch  low  density  diskettes  (360  kb) 

90M  Bernouili  disk 


SUPPORTING  DOCUMENTATION 


Interface  Control  Document  For  the  Memory  LoaderA/erifier  with 
T^aetical  Avionic  S/stem,  date  8  July  1985,Tasued  b7 
Naval  Air  Development  Center,  Code  3021 , 

Warminster  Pennsylvania  18974-5000. 


»00lS 


OHS  HDVH  H/VfrT  -1 


-^£6_688  S08S  ae.-CT  aszes/ii 
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SETUP 


3.1  PC 

3.1.1  Place  the  "Source"  switch  in  the  DMLV  position  (see  figure  2). 

3.1.2  Switch  on  Power  Strip  (see  figure  1). 

3.1.3  Place  the  Bernoulli  disk  in  drive  C. 

3.1.4  The  WRA  load  station  software  is  run  automatically  on  power  up. 

3.2  LVTS/DMLV 

3.2.1  When  performing  LVTS  ooerations  place  the  "Source"  switch  in  the 

LVTS  position  (see  figure  2). 

3.2.2  Connect  the  L'vTS  aircraft  connectors  to  the  MLV  Panel  (see  figure  1) 


u 

L. 
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FIGURt  2 


3.3  WRA 

3-3  PI3C6  ths  dssirsd  WRA  in  its  3lioc3t@d  slot  (figure  1) 

NOTE;  Two  people  are  required  to  lift  the  ARDP. 

3.3.2  Connect  appropriate  WRA  cables. 

3.3.3  MISSION  COMPUTER  (MC) 

3.3.3. 1  MC1  operations 

Place  the  "MC"  switch  in  the  MC1  position  (see  figure  2). 

3. 3. 3. 2  MC2  operations 

Place  the  “MC"  switch  in  the  MC2  position  (see  figure  2). 

3.3.4  DISPLAY  PROCESSOR  (DP) 

3.3.4. 1  DP1  operations 

Place  the  "DP"  switch  in  the  DPI  position  (see  figure  2). 

3.3. 4. 2  DP2  operations 

Place  the  "DP"  switch  in  the  DP2  position  (see  figure  2). 

3.3.5  Converter  Interface  Unit  (CIU) 

3.3.5. 1  Place  the  CIU  Air  Plenum  Adapter  in  front  of  the  Airborne  Radar  Data 
Processor  (ARDP)  Air  Plenum. 

3.3.5.2  Place  the  CIU  Adapter  Guide  in  the  Adapter  Guide  Location  on  the  ARDP  shelf 

3.3. 5. 3  Connect  the  CIU  Adapter  Cables  to  the  CIU  and  the  ARDP  cables. 

3.3.6  Turn  ON  the  400HZ  Power  Converter,  if  installed  (see  figure  1 ). 

3.3.7  Place  the  60HZ  power  switch  to  the  ON  position  (see  figure  3). 

3.3.8  Place  the  400HZ  power  switch  to  the  ON  position  (see  figure  3). 
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FI'^URE 


3.3.9  Place  the  power  switch  for  the  desired  WRA  in  the  ON  position  (see  fioure  2). 

NOTE;  Only  one  WRA  can  be  loaded  at  a  time. 

Only  one  WRA  power  switch  should  be  on  at  a  time. 

4  MENU  OPERATIONS 

At  power  up.  the  PC  will  display  a  title  screen  which  identifies  the  unit  This 
consists  of  the  following  information: 

o  Title 

0  WRA  Load  Station  part  number 
o  Serial  number 
o  Classification 
0  Current  time 
0  Current  date 

At  this  time  the  operator  should  verify  that  the  time  and  date  displayed  are 
correct.  Functions  are  provided  to  set  time  (F1  key)  or  date  (F5  key).  The 
proper  formats  for  time  and  date  entry  are  displayed  in  their  respective  prompt 
windows.  After  the  title  screen  is  displayed  the  Discrete  I/O  Card  Confidence 
Test  is  mn.  This  verifies  that  the  computer  is  able  to  communicate  with  the 
GAC  Discrete  I/O  card.  When  the  test  is  completed  the  Main  Menu  is 
displayed.  The  menu  appears  as  follows; 

LOAD  W/AUTO  VERIFY 
VERIFY 
SAVE 

DISPLAY  LIBRARY 
DELETE  FILE 
DISK  OPERATIONS 
SHUTDOWN 

The  UP  and  DOWN  arrow  keys  are  used  by  the  operator  to  highlight  the 

operation  desired.  PressRETURNkey  to  perform  the  selected  operation  The 
Main  Menu  will  return  after  the  completion  of  the  selected  operation. 
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TSDF  UPGRADE 
RECOMMENDATIONS 


4  Sep  96 


Memorandum 

To:  Cheryl  McCombs,  Hector  Diaz 

From:  The  TSSA  DesignyLab  Team 

Subj:  TSDF  Equipment  Upgrades 

Enel:  (1)  Equipment  Lists  and  Approximate  Costs 

(2)  IBM  Compatible  PC  Usage 

1 .  The  near  term  focus  for  upgrades  to  the  TSDF  is  on  increased  efficiency/capabilities 
with  the  current  development  environment  and  on  developing  automated  systems  for 
software  tracking  and  documentation  efforts.  This  memo  does  not  cover  TSDF  upgrade 
efforts  covered  by  the  procurement  of  the  2F169  development  system,  the  ATIP  Phase  I 
upgrades  to  the  MT  suite,  or  the  PAX  Best  Value  OFT  update. 

2 .  The  major  areas  of  immediate  concern  in  the  TSDF  are; 

a)  Storage  capacity  on  the  F-14D  system. 

b)  The  development  environment  (all  training  devices). 

c)  Automated  documentation  capabilities  (all  training  devices). 

d)  Development  of  automated  software  CM  tools. 

3.  In  order  to  accomplish  the  most  with  the  smallest  financial  outlay,  the  purchase  of 
Personal  Computer  based  systems  is  proposed.  The  feasibility  of  utilizing  PC  interfaces 
with  the  Encore  system  has  already  been  demonstrated  in  the  TSDF  using  the  Gateway  PC 
purchased  for  the  2F169  system.  See  enclosure  (2)  for  summaries  of  the  proposed 
tasks/applications  that  a  few  multi-purpose  systems  can  provide.  See  enclosure  (1)  for 
approximate  system  costs  of  hardware  and  supporting  software. 

4.  Until  alternative  PC  based  storage  devices  for  the  F-14D  can  be  demonstrated,  there 
is  an  immediate  need  to  purchase  SCSI  disks  for  the  TSDF.  The  need  to  maintain  spare 
disks  on  the  East  Coast  for  development,  and  the  need  to  store  multiple  baselines  and  SMT 
databases  (cross-references,  etc)  for  upcoming  documentation/development  effons  requires 
added  capacity  in  the  TSDF.  The  current  non-availability  of  1.2GB  SCSI's  will  also 
necessitate  a  MPX  patch  to  support  the  newer  4GB  disks.  See  enclosure  (1)  for 
approximate  system  costs  of  hardware  and  supporting  software. 

5 .  A  switching  unit  is  needed  to  select  the  magnetic  tape  unit  to  either  F-14D  computer 
(the  9780  or  the  9750)  in  the  TSDF.  This  is  currently  accomplished  by  opening  the  unit 
and  manually  disconnecting/reconnecting  the  ribbon  cables  for  each  machine.  This  is  an 
unacceptable  method  which  is  prone  to  eventually  breakage.  A  low  cost  switching  unit 
could  alleviate  this  problem. 

6.  The  costs  and  equipment  detailed  here  are  based  upon  the  complete  lack  of 
knowledge  of  available  funds  for  TSDF  improvements.  When  an  approximate  budget  and 
procurement  schedule  is  made  available,  these  estimates  can  be  tailored  to  fit  the  most 
immediate  needs.  Especially  in  the  area  of  the  individual  PC  systems,  the  flexibility  in 
packaging  options  from  vendors  provides  extensive  opportunities  to  customize  systems  to 
fiscal  constraints.  The  list  is  also  unprioritized,  again  based  upon  the  lack  of 
scheduling/funding  availability. 


Enclosure  2:  IBM  Compatible  PC  Usage 


1 .  UNIX  operating  system.  The  2F169  operates  on  a  UNIX  based  computer 
system.  Until  we  have  the  2F169  system  in  the  lab,  it  is  important  that  we  maintain  at  least 
one  system  with  the  UNIX  O/S.  We  not  only  need  to  develop  script  files  that  will  assist 
us  our  development  efforts,  but  we  also  have  to  maintain  proficiency  with  the  O/S. 

2.  MS  Access  database  management.  The  2F169  symbol  database  is  a  Microsoft 
Access  based  relational  database.  We  need  access  to  this  application  to  evaluate  NG 
software  tools  and  processes,  as  well  as  developing  our  own. 

3 .  CM  development  We  currently  are  in  need  of  automated  CM  tools  to  track 
software  changes.  A  PC  connected  to  the  development  systems  in  the  lab  will  not  only 
allow  us  to  access  files,  but  we  can  build  a  software  interface  that  will  track  file  revision 
levels,  associated  changes,  responsible  engineers,  etc. 

4.  File  storage.  On  the  F-14D  system,  we  have  a  shortage  of  SCSI  disks.  By 
utilizing  PC  based  storage  media,  we  can  alleviate  this  problem.  There  are  multiple  PC 
storage  configurations  that  can  be  used  for  backups,  and  that  are  readily  transported  to 
other  platforms. 

5.  Transportability.  Being  able  to  load  software  baselines,  CM  databases,  and  even 
executable  tasks  onto  PC  based  storage  devices  allows  us  to  readily  and  conveniently 
transport  files  between  sites.  Mailing  SCSI  disks  between  sites  seems  unrealistic  due  to 
the  reliability  of  the  SCSI  and  our  lack  of  them.  A  PC  based  media  would  provide  us  a 
reliable  and  more  transportable  backup  to  the  magnetic  tapes. 

6 .  Maintainability.  If  data  on  the  maintainability  and  upgradability  of  IBM  compatible 
PCs  vice  that  of  our  current  equipment  is  needed,  it  will  be  provided. 

7.  Terminal  Emulation.  The  current  lab  configuration  utilizes  out  of  date  text 
terminals  which  display  80x24  characters.  The  120  character  mode  is  illegible.  Many  files 
exceed  the  80  column  display  area  and  are  difficult  to  work  with.  Replacing  the  current 
terminals  with  PC  based  monitors  would  not  only  provide  acceptable  user  friendly 
displays,  but  when  combined  with  file  transfer  capability,  would  also  give  multi-window 
editors  (vice  the  current  Encore  line  editor). 

8 .  TSS  A  Documentation  Efforts.  With  a  file  transfer  capability,  design 
documentation  can  be  automatically  generated  in  an  already  accepted  format.  This  has 
been  demonstrated  on  the  F-14D  already  by  generation  of  DBDD  change  pages. 

Generation  of  the  3(X)+  pages  was  accomplished  by  downloading  the  needed  files  (<  2hrs) 
and  then  reformatting  the  document.  The  file  transfer  ability  improves  not  only  the  speed  at 
which  documents  can  be  generated,  it  also  improves  accuracy. 

9.  Log  file  generation.  The  PC  can  be  used  to  capture  screen  data  and  also  to  build  a 
log  file,  such  as  used  during  the  on-site  coldstart  process.  This  is  a  useful  function  in 
documenting  processes  (captures  not  only  output,  but  also  the  input  commands)  and  in 
logging  output  that  is  echoed  to  the  screen  only. 

10.  Classified  Work.  PCs  with  removable  hard  disks  could  readily  be  used  in  the  lab 
for  classified  efforts. 


1 1 .  Contractor  Documentation  Review.  Several  documents  (Classified  appendix  for 
the  F-14B/A  SDDD  and  the  unclassified  SDDD  appendices  for  the  F-14D)  have  already 
been  delivered  in  media  format  The  PCs  in  the  TSDF  could  also  be  utilized  for  the 
review  efforts  there. 


APPENDIX  K 


CONFIGURATION  MANAGEMENT 
SOFTWARE  TOOL 
DATA  SHEETS 


October  24, 1996 


“  .  !|8oft 


soitware 


Mr.  Clark  L.  Morris 

Dual  Inc. 

30  Skyline  Inc. 

Lake  Mary ,  FL  32746 
USA 

Dear  Mr.  Morris  : 

Thank  you  for  your  interest  in  ADC/Pro™.  True  Software  has  brought  a  "natural 
approach"  to  version  control  and  change  management  with  its  TRUEchange  rapid 
team  development  solution  that  manages  the  implementation  and  roll-out  of 
software  changes. 

ADC /Pro’s  TRUEchange  rapid  team  development  system  helps  software  teams 
dramatically  reduce  the  time  it  takes  to  respond  to  changing  market  conditions  by 
enabling  them  to  efficiently  implement  and  roll-out  changes  to  stay  on  top  of  ever 
accelerating  release  cycles.  Unlike  version  control  and  configuration  management 
tools  that  treat  each  change  to  a  file  as  a  separate  delta,  ADC /Pro  groups  related 
modifications  across  multiple  files  in  a  single  logical  unit:  a  change-sef”.  Developers 
can  add  or  remove  specific  change-sets  to  software  releases  and  variants,  managing 
projects  in  the  natural  context  of  problem  fixes  and/or  enhancements. 

ADC /Pro  is  ideally  suited  for  Information  Technology  departments  who  perform  a 
high  volume  of  software  changes;  who  operate  across  Windows,  Windows  NT,  Unix, 
and  VMS  platforms;  who  require  a  secure  environment  to  protect  their  software 
assets;  and  who  must  synchronize  work  across  teams,  locations,  releases,  and 
customized  application  variants. 

I  am  enclosing  literature  that  will  introduce  you  to  the  power  of  ADC /Pro.  If,  after 
looking  over  the  enclosed  literature  you  would  like  more  detailed  technical 
information  about  ADC/Pro,  please  feel  free  to  call  your  account  representative, 
Stephan  Reekie,  at  (508)  369-7398  x226.  You  may  want  to  check  out  our  web  site  at 
www.truesoft.com!  Thanks  again  for  considering  ADC/Pro  for  your  software 
configuration  management  needs. 

Sincerely, 


Pat  Bolis 

Marketing  Specialist 


200  Baker  flvenoe,  Suite  300,  Conceril,  fUfl  01/42  /  Tel:  508-369-/398  /  fax:  508-369-82/2  /  e-mail:  infootroesoft.com 
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Change 


If  you  develop  software,  you  battle  daily  with  change. 

•  Changing  market  demands. 

•  Changing  technology. 

•  Changes  to  your  products. 


You  can't  hide  from  it,  you  can't  stop  it,  you  can't  control  it,  but  with  True  Software's 
Aide-de-Camp™/Pro  SCM  solution,  you  can  finally  manage  change  effectively. 

As  a  sophisticated  developer,  you  want  more  than  file  versioning  and  release  support.  You 
want  to  manage  the  logical  changes  required  to  meet  shifting  marketing  and  technical 
specifications.  You  need  Aide-de-Camp/Pro,  the  logical  approach  to  software  configuration 
management. 


Every  other  software  configuration  management  (SCM)  tool  manipulates  individual  edits  to 
individual  files.  Aide-de-Camp/Pro  (ADC™/Pro)  treats  software  changes  the  way  experienced 
developers  do:  as  logical  change  sets,  each  of  which  contains  all  the  edits  that  implement  the 
change.  While  you  focus  on  the  functional  changes  as  a  whole,  ADC/Pro  takes  care  of  the 
details. 


Shorter  Time  To  Market  With  Team  Development 

With  ADC/Pro,  your  teams  can  work  concurrently  on  the  same  files  and  in  parallel  on 
multiple  development  paths.  Code  reuse,  version  configuration,  and  impact  analysis  promote 
high-quality  code  across  multiple  changes  by  multiple  users  -  without  maintenance  headaches 
and  version  proliferation,  which  are  as  ubiquitous  as  change  itself 


Smart  Code  Reuse  for  Lower  Costs 

With  ADC/Pro's  extraordinary  software  migration  capabilities,  you  can  reduce  costs  by 
making  the  most  of  existing  code.  ADC/Pro  is  the  only  SCM  solution  that  empowers  you  to 
migrate  a  single  logical  change  to  any  other  version  or  product.  You  pick  the  change  set,  and 
ADC/Pro  automatically  integrates  the  correct  code  with  the  desired  release.  You  also  can 
merge  multiple  branches  of  development  paths.  ADC/Pro  consolidates  any  number  edits, 
across  any  number  of  files,  within  any  number  of  change  sets. 


1  of4 


To  keep  costs  down,  however,  you  need  to  get  it  right  the  first  time.  As  you  merge  and  migrate 
software,  ADC/Pro  automatically  detects  conflicts.  You  resolve  the  conflicts  simply  by 
clicking  on  the  desired  variant  or  editing  the  target  version  in  an  easy-to-understand  display. 
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You  save  precious  days  -  or  even  weeks  -  traditionally  wasted  reworking  changes  across 
multiple  development  paths. 


Ultimate  Quality  Control 

ADC/Pro  continuously  enforces  criteria  for  version  configuration.  You  define  each  release  up 
front.  You  and  your  colleagues  develop  and  test  software  throughout  the  entire  development 
phase  in  the  context  of  the  release  -  without  the  nightmare  of  mismatched  software  subsystems 
and  unintentional,  last-minute  mix-ups. 

ADC/Pro  is  the  only  SCM  solution  to  support  intelligent  impact  analysis.  You  can  use  any  of 
ADC/Pro's  language-specific  scanners  (for  C,  C++,  COBOL,  FORTRAN,  or  Ada),  which 
dynamically  capture  the  relationships  and  dependencies  established  by  software  structures 
within  the  source  code.  With  this  information,  you  can  determine  the  impact  of  any  change 
before  you  make  it.  ADC/Pro  itself  uses  this  information  to  ensure  that  releases  contain  all  the 
required  files. 


Managing  the  SCM  Process  Your  Way 

You  want  a  well-defined  software  development  process  that  fosters  productivity  and  quality. 
Some  SCM  tools  leave  process  management  up  to  the  project  leaders  themselves.  Other  tools 
provide  fixed  rules  that  "transparently"  control  the  SCM  process.  With  ADC/Pro's 
customizable  Process  Manager,  you  can  manage  the  development  process  your  way. 

The  Process  Manager  manages  all  ADC/Pro  operations  per  your  preferences.  It  determines  the 
steps  of  the  software  development  process:  file  checkout  and  checkin,  branching  and  merging, 
change  migration,  version  definition,  code  freezes,  and  releases,  etc.  It  also  governs  role-based 
user  privileges,  table-driven  phases  of  development,  definition  of  attributes  and  relationships, 
version  naming  conventions,  and  user  notifieation  of  events  via  electronic  mail.  The  Process 
Manager  not  only  manages  change;  it  accommodates  it.  You  can  put  the  Process  Manager  to 
use  straight  out  of  the  box,  taking  advantage  of  the  clear,  predefined  scripts.  You  also  can 
modify  the  Process  Manager  or  build  entirely  new  scripts  to  meet  company-specific 
requirements.  You  adjust  the  Process  Manager  to  serve  your  needs  today  and  well  into  the 
future. 


A  Match  For  Any  Development  Environment 

You  want  an  SCM  solution  that  works  in  the  same  environment  you  do.  ADC/Pro  can  handle 
whatever  you  can  -  including  all  your  files,  software  tools,  and  networked  platforms. 

Whether  you  build  procedural,  functional,  or  object-oriented  source  code,  ADC/Pro  handles 
your  source  files,  specifications,  documentation,  test  plans,  SQL  programs,  and  even  binary 
files.  ADC/Pro  manages  the  primary  and  ancillary  files  you  need  to  fully  define  your  product. 

ADC/Pro  even  facilitates  integration  and  customization  of  third-party  software  source  code. 
The  graphical  load,  impact  analysis,  merge,  and  conflict  resolution  tools  automatically 
incorporate  vendors'  updates  into  your  current  version  of  their  products  while  protecting  the 
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local  changes  you  have  already  made.  You  no  longer  have  the  headache  of  wading  through  all 
the  changes,  file  by  file.  ADC/Pro  is  platform  independent  to  run  without  modification  in  both 
homogeneous  and  heterogeneous  environments  and  across  distributed  networks  of  UNIX®, 
VMS™,  DOS®  and  Windows™  95  and  Windows  NT  systems.  ADC/Pro  clients  everywhere 
on  the  network  use  the  same  commands  and  procedures  to  access  ADC/Pro  servers  running  on 
any  supported  operating  system.  Your  users  can  sit  at  any  workstation  or  PC  on  the  network 
without  compromise. 


Working  With  the  Experts 

You  want  to  work  with  the  experts.  True  Software  consultants  offer  you  an  average  of  ten 
years  of  SCM  experience.  Our  services  staff  is  available  before  you  select  an  SCM  product,  to 
help  define  your  SCM  needs.  After  you  install  ADC/Pro,  our  professionals  can  jump-start 
your  SCM  process.  As  you  continue  to  work  with  ADC/Pro,  we  can  maximize  the  benefits  of 
the  only  change  management  solution  available  in  the  SCM  marketplace. 


ADC/Pro  Helps  You  Manage  Change 

Logical  change  management  vs.  arbitrary  file  management 

•  Intelligent  repository 

•  Patent-pending  change  set  technology 

•  Customizable  Process  Manager 

•  Change-set-based  version  configuration 

Faster  programming 

•  Concurrent  development 

•  Parallel  development 

•  Version  merging 

•  Migratable  change  sets 

Cleaner  code 

•  Conflict  detection  and  resolution 

•  Impact  analysis 

•  Tracking  and  management  tools 

•  Flexible,  productive  development  environment 

•  Platform-independent  development  scripts  and  user  interface 

•  Distributed  code  management 

•  Customizable  graphical  interface 

•  Accessible  command-line  interface 

•  Support  for  all  source  code  and  other  text  files,  extended  by  language-specific  scanners 
for  code  written  in  C,  C-H-,  COBOL,  FORTRAN,  and  Ada 
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s  ^  sophisticated  developer,  you  want  more  than  file  versioning  and  release  management.  You  want 
to  manage  the  logical  changes  required  to  meet  shifting  marketing  and  technical  specifications.  You  need 
Aide-de-Camp'/Pro,  the  logical  approach  to  software  configuration  management. 

Every  other  software  configuration  management  (SCM)  tool  manipulates  individual  edits  to  individual  files. 
Aide-de-Camp/Pro  (ADC  /Pro)  treats  software  changes  the  way  experienced  developers  do:  as  logical 
change  sets,  each  of  which  contains  all  the  edits  that  implement  the  change.  While  you  focus  on  the  functional 
change  as  a  whole,  ADC /Pro  takes  care  of  the  details. 
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With  ADC /Pro,  your  teams  can  work  concurrently  on  the  same  files  and  in  parallel  on  multiple  development 
paths.  Code  reuse,  version  configuration,  and  imj^S*%nalysis  promote  faster  development  of  high-quality 
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code  across  multiple  changes  by  multiple  users  —  without  maintenance  headaches  and  version  proliferation, 
which  are  as  ubiquitous  as  change  itself. 


SiRRT  CODE  REOSE  FOR  LOOIER  COSTS 


With  ADC /Pro's  extraordinary  change  migration  capabilities,  you  can  reduce  costs  by  making  the  most  of 
^  existing  code.  ADC /Pro  is  the  only  SCM  solution  that  empowers  you  to  migrate  a  single  logical  change  to  any 
other  version  or  product.  You  pick  the  change  set,  and  ADC/Pro  automatically  integrates  the  correct  code 
with  the  desired  release.  You  also  can  merge  multiple  branches  of  development  paths.  ADC /Pro  consolidates 


any  number  of  edits,  across  any  number  of  files,  within  any  number  of  change  sets. 


To  keep  costs  down,  however^  you  need  to  get  it  right  the  first  time.  As  you  merge  and  migrate  software, 
ADC /Pro  automatically  detects  f^^q^^t^^foi^esolve  the  conflicts  simply  by  clicking  on  the  desired  variant  or 
editing  the  target  version  in  an  save  precious  days  -  or  even  weeks  - 

traditionally  wasted  reworking  changes  across  multiple  development  paths. 
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ADC/Pro  continuously  enforces  criteria  for  version  configuration.  You  define  each  release  up  front.  You  and 
your  colleagues  develop  and  test  software  throughout  the  entire  development  phase  in  the  context  of  the 
release  -  without  the  nightmare  of  mismatched  software  subsystems  and  unintentional,  last-minute  mix-ups. 

ADC/Pro  is  the  only  SCM  solution  to  support  intelligent  impact  analysis.  You  can  use  any  of  ADC/Pro's 
f  A.-_  Isi'gu^gS'Specific  scanners  (for  C,  C+-t,  COBOL,  FORTRAN,  or  Ada),  which  dynamically  capture  the 
relationships  and  depenidlencies'esfablished  bv  software  structures  within  the  snurre  mde  With  thic 
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You  want  a  well-defined  software  development 
process  that  fosters  productivity  and  quality.  Some 
SCM  tools  leave  process  management  up  to  the  pro¬ 
ject  leaders  themselves.  Other  tools  provide  fixed 
rules  that  '"transparently"  control  the  SCM  process. 
With  ADC /Pro's  customizable  Process  Manager,  you 
can  manage  the  development  process  your  way. 

The  Process  Manager  manages  all  ADC /Pro  opera¬ 
tions  per  your  preferences.  It  determines  the  steps  of 
the  software  development  process:  file  checkout  and 


You  want  an  SCM  solution  that  works  in  the  same 
environment  you  do.  ADC /Pro  can  handle  whatever 
you  can  -  including  all  your  files,  software  tools,  and 
networked  platforms. 

Whether  you  build  procedural,  functional,  or  object- 
oriented  source  code,  ADC /Pro  handles  your  source 
files,  specifications,  documentation,  test  plans,  SQL 
programs,  and  even  binary  files.  ADC /Pro  manages 
the  primary  and  ancillary  files  you  need  to  fully 
define  your  product. 


checkin,  branching  and 
merging,  change  migration, 
version  definition,  code 
freezes,  and  releases,  etc.  It 
also  governs  role-based 
user  privileges,  table-driven 
phases  of  development, 
definition  of  attributes  and 
relationships,  version  nam¬ 
ing  conventions,  and  user 
notification  of  events  via 
electronic  mail. 

The  Process  Manager  not 


ADC /Pro  even  facilitates 
integration  and  customiza¬ 
tion  of  third-party  software 
source  code.  The  graphical 
load,  impact  analysis, 
merge,  and  conflict  resolu¬ 
tion  tools  automatically 
incorporate  vendors'  up¬ 
dates  into  your  current  ver¬ 
sion  of  their  products  while 
protecting  the  local  changes 
you  have  already  made. 
You  no  longer  have  the 


only  manages  change;  it  accommodates  it.  You  can 
put  the  Process  Manager  to  use  straight  out  of  the 
box,  taking  advantage  of  the  clear,  predefined  scripts. 
You  also  can  modify  the  Process  Manager  or  build 
entirely  new  scripts  to  meet  company-specific 
requirements.  You  adjust  the  Process  Manager  to 
serve  your  needs  today  and  well  into  the  future. 


headache  of  wading  through  all  the  changes,  file 
by  file. 

ADC /Pro  is  platform  independent  to  run  without 
modification  in  both  homogeneous  and  heteroge¬ 
neous  environments  and  across  distributed  networks 
of  UNIX',  VMS'",  DOS,  and  Windows  systems. 
ADC /Pro  clients  everywhere  on  the  network  use  the 
same  commands  and  procedures  to  access  ADC /Pro 
servers  running  on  any  supported  operating  system. 
Your  users  can  sit  at  any  workstation  or  PC  on  the 
network  without  compromise. 
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^U  oday's  engineering  manager  copes  with  virtually 
unmanageable  complexity  while  delivering 
more  in  less  time.  Something  that  you  can't  avoid  - 
change  -  further  confounds  this  paradoxical  dilemma. 
Complexity  and  change  run  rampant  in  the  world  of 
engineering: 

•  Technology  advances  in  hardware,  software, 
and  communications 

•  Evolving  software  development  tools  and  techniques 

•  Increasingly  large  software  systems 

•  Fluctuating  customer  requirements 

•  Ever-rising  expectations  for  better  quality  and 
performance  at  a  lower  cost 

•  Rapidly  diminishing  time-to-market  opportunity 

This  shifting  environment  stumps  even  the  most 
diligent  efforts  to  produce  high  quality  software  on 
time.  In  fact,  the  result  is  often  poor  quality  and 
lower  productivity. 

The  problem  of  change  escalates  exponentially  when 
organizations  implement  a  team  engineering  environ¬ 
ment  or  require  teams  to  work  in  concert  on  a  suite  of 
products.  Their  problems  do  not  lie  in  managing  the 
work  of  individual  developers  but  in  coordinating  the 
work  of  multiple  team  members  at  different  locations 
across  many  projects.  These  organizations  face  critical 
obstacles  to  growth  and  excellence. 

To  handle  the  vagaries  of  change,  intelligent  software 
engineers  are  turning  to  software  configuration 
management  (SCM)  solutions.  At  True  Software”,  we 
understand  that  software  developers  have  to  manage 
change  in  a  manner  that  actually  accommodates  it. 
We  help  engineers  solve  the  problems  of  today  with 
SCM  solutions  that  embrace  the  inevitable  changes  of 
tomorrow. 


WITH 


You  want  to  work  with  the  experts.  True  Software  consultants 
offer  you  an  average  of  ten  years  of  SCM  experience.  Our 
services  staff  is  available  before  you  select  an  SCM  product,  to 
help  define  your  SCM  needs.  After  you  install  ADC/Pro,  our  pro¬ 
fessionals  can  jump-start  your  SCM  process.  As  you  continue  to 
work  v\ath  ADC/Pro,  we  can  maximize  the  benefits  of  the  only 
change  management  solution  available  in  the  SCM  marketplace. 

iDC/fl  HELPS  you  DlllOiieE  CHUOfiE: 
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•  Intelligent  repository 

•  Patent-pending  change  set  technology 

•  Customizable  Process  Manager 

•  Change-set-based  version  configuration 


•  Concurrent  development 

•  Parallel  development 

•  Version  merging 

•  Migratable  change  sets 


Aide-de-Camp/Pro 
SCM  SOLUTION, 
YOU  CAN  FINALLY 
MANAGE  CHANGE 
EFFECTIVELY. 


□  I  want  more  information  about 
Aide-de-Camp/Pro. 

□  I  want  more  information  about 
True  Software's  professional  services. 

□  I  want  a  True  Software  sales 
representative  to  call  me. 


CLEBBEB  COOE 


•  Conflict  detection  and  resolution 

•  Impact  analysis 

•  Tracking  and  management  tools 


flEXIBLE,.  PBOOUCTIVE  DEVELOPfllEBT  EBVIBflBIBEOT 


Platform-independent  development  scripts  and  user  interface 
Distributed  code  management 
Customizable  graphical  interface 
Accessible  command-line  interface 

Support  for  all  source  code  and  other  text  files,  extended  by 
language-specific  scanners  for  code  written  in  C,  C-t-f, 
COBOL,  FORTRAN,  and  Ada 


Name _ 
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Organization _ 

Address _ 

City _ 

State/Province- 
Zip /Postal  code 

Country _ 

Phone _ 

Fax _ 

E-mail _ 
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The  AlliedSignal  Engines  software 
group  concurrently  supports  over 
1,500  versions  of  their  software 
that  run  on  33  operating  systems 
and  93  hardware  platforms. 

"With  every  engine,  we  ship  a 
customer  deck  —  a  set  of  software 
programs  that  help  our  customers 
evaluate  engine  performance 
within  their  aircraft,"  explains 
David  Stoklas,  Senior  Systems 
Programmer  in  charge  of  software 
configuration  management  (SCM). 
"Each  software  deck  is  complex, 
often  consisting  of  over  750  lines 
of  code.  We  tailor  each  deck  to  the 
particular  computer  platforms  and 
aircraft  engine  configurations  at 
each  customer  site.  Because  no 
customer  receives  every  module 
or  subroutine,  there  can  be  as 
many  as  25  layers  of  if-then 
statements  just  to  decide  what 
code  to  compile." 

AlliedSignal  Engines  also  faces 
the  transitions  associated  with 
ever-changing  technology.  They 
recognized  the  need  to  migrate 
from  their  mainframes  to  a 
client/server  environment  for 


more  flexibility,  lower  costs,  and 
increased  performance  at  the 
hands  of  the  developers  and 
designers.  The  department  was 
moving  their  software  develop¬ 
ment  from  two  Control  Data  Corp 
mainframes  to  a  configuration  of 

Concludes  Stoklas: 

"We  needed  an  SCM  engine 
that  was  up  to  the  challenge." 

Hewlett-Packard's  HP  715-50 
and  HP  715-100  workstations  net¬ 
worked  to  three  HP  G70  servers, 
including  a  Model  800  with  dual 
Model  700  CPUs.  While  the  HP 
systems  run  HP/UX,  several 
SPARC  workstations  run  Solaris, 
and  DEC  VAX  workstations, 
which  drive  engine  performance 
analysis  on  the  production  floor, 
run  ULTRIX.  In  all,  over  400 
workstations  run  on  the  network. 

Concludes  Stoklas:  "We  needed 
an  SCM  engine  that  was  up  to  the 
challenge." 


liedSignal  Engines  installed 
We-de-Camp (ADC’’''^’)  in 


February  of  1994.  "We  chose 
Aide-de-Camp  because  it  was 
extremely  flexible  and  easy  to  adapt 
to  our  situation,"  Stoklas  recounts. 


"We  chose  ADC 
because  it  loas  the  only  one 
that  can  handle  the  kind  of  thing 
we  need  to  feed  it." 


"Too  many  code  maintenance 
environments  make  the  assump¬ 
tion  that  you're  a  C  programmer 
working  in  a  university  environ- 
ent;  they  only  do  little,  short 
ings  like  quick  tests  and  compiles 
—  fun  and  games.  The  custom 
code  we  write  involves  complex 
algorithms  employing  advanced 
physics  and  thermodynamic 
parametric  equations." 

"Some  of  these  programs  are  so 
long  that  an  IBM  3090  mainframe 
FORTRAN  compiler  can't  handle 
them.  While  other  tools  would  go 
belly  up  and  die,  ADC  can  digest 
200-thousand-line  FORTRAN 
programs  with  no  problem.  We 
chose  ADC  because  it  was  the 
only  one  that  can  handle  the  kind 
of  thing  we  need  to  feed  it." 

pklas'  group  came  up  to  speed 
"quickly  and  found  ADC  easy  to 
use.  Within  six  months,  the  group 
had  already  loaded  in  over  three 
million  lines  of  code.  The 


organization  took  advantage  of 
ADC's  multiplatform  support  and 
its  adaptability  to  different  envi¬ 
ronments.  Stoklas  says,  "ADC  is 
platform  independent,  meaning 
we  can  use  one  database  for  all 
our  development,  and  all  the 
commands  work  the  same  way 
everywhere  on  the  network." 

AlliedSignal  uses  an  internal  SCM 
process  called  DUCK  —  short  for 
Darn  Ugly  Code  Killer  —  to  track 
each  piece  of  code  in  terms  of  its 
function,  platform,  operating 
system,  and  product.  ADC  now 
manages  the  AlliedSignal  SCM 
process  —  per  DUCK  specifications. 
To  accomplish  this,  ADC  handles 
changes  in  terms  of  their  logical 
functions. 

"Your  configuration 
management  system 
can  be  a  lifeline, 
when  everything  around  you 
is  changing. " 
reports  Stoklas. 

"We  would  be  in  deep  trouble 
without  ADC." 

While  most  SCM  systems  only 
track  edits  to  physical  files,  ADC 
uses  change  sets  to  manage  all  the 
edits  that  implement  a  single 
logical  change,  such  as  an  engine 
test  modification.  Change  sets 
allow  AlliedSignal  Engines  to 


identify  each  software  component 
or  change  by  function.  Change 
sets  underlie  AlliedSignal's  ability 
to  do  the  logical  labeling  and 
packing  necessarv  to  make  sure 
that  everything  ends  up  where  it 
is  supposed  to. 

ADC  also  accommodates  the  need 
for  security.  AlliedSignal  maintains 
separate  ADC  repositories  to  guar¬ 
antee  the  split  between  government 
and  civilian  code.  The  company 
can  build  the  software  decks  with 
confidence  and  then  ship  them  in 
machine-readable  format  to  protect 
the  proprietary  algorithms  and  data 
used  internally  to  build  the  engines. 

"Your  configuration  management 
system  can  be  a  lifeline,  when  every¬ 
thing  around  you  is  changing." 
reports  Stoklas.  "We  would  be  in 
deep  trouble  without  ADC." 
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The  Aide-de-Camp''‘'''/Pro  envi¬ 
ronment  includes  a  fully  defined 
Process  Manager  that  allows 
you  to  manage  your  software 
development  process  exactly  the 
way  you  want.  You  can  employ  the 
customizable  Process  Manager 
right  out  of  the  box  to  carry  out  any 
current  or  evolving  SCM  process. 

The  Aide-de-Camp  (ADC^^’l/Pro 
Process  Manager  guides  you 
through  the  steps  of  software 
configuration,  invoking  ADC /Pro 
routines  so  that  you  maintain  com¬ 
plete  control.  Die  Process  Manager 
consists  entirely  of  easily  edited 
scripts  —  collections  of  ADC /Pro 
commands  that  define  and  govern 
user  access  privileges,  naming 
conventions,  preferred  phases  of 
development,  and  available  attributes 
and  relationships.  The  Process 
Manager  scripts  also  regulate  all 
ADC /Pro  operations,  including 
checkin  and  checkout,  migration  and 
merging,  and  reference-area  updates. 

Governing  Daily  Operations 
The  Process  Manager  actually 
underlies  all  ADC/Pro  operations, 
automating  and  controlling  how 


PMCESS  iniimEI! 


you  and  your  colleagues  work 
with  the  software.  The  Process 
Manager  is  powerful  enough  to 
perform  a  series  of  operations  based 
on  users'  actions.  For  example, 
whenever  a  developer  checks  in  a 
change  set,  ADC /Pro  can  place 
the  changes  in  a  holding  directory 
and  inform  you,  the  project  leader, 
that  the  files  are  ready.  You  can 
promote  the  changes  when  you 
have  reviewed  and  approved  them. 

True  Team  Development 
The  Process  Manager  not  only 
supports  team  engineering  —  it 
encourages  it.  The  Process 
Manager  is  ideal  for  teams  that 
work  in  parallel  on  multiple 
versions  of  the  same  set  of  source 
code;  ADC /Pro  is  the  only  SCM 
solution  that  makes  it  easy  to  merge 
changes  from  one  branch  to  another 
and  to  selectively  migrate  changes 
from  one  version  to  another.  The 
Process  Manager  also  can  prevent 
or  support  concurrent  development 
by  either  prohibiting  simultaneous 
checkout  or  by  facilitating  fast, 
painless,  safe  coordination  of 
simultaneous  changes. 


You  want  a  well  defined  software  development  process  that  fosters  i 
productivity  and  quality.  Some  SC!M  tools  implement  expensive  workflow  | 
models  that  rely  on  existing  file-versioning  mechanics.  Others  address 
only  a  limited  area  of  the  SCM  process,  such  as  build  management. 

Only  ADC's  customizable  Process  Manager  empowers  you  to  manage  true 

team  development  —  exactly  the  way  you  want  —  with  ease  and  reliability. 

-  ■ 


jnrisuraole  'ocunrv 
As  a  security  tool,  the  Process 
Manager  offers  a  logical,  flexible 
way  to  manage  access  privileges, 
based  on  user  types  and  the 
commands  that  they  may  invoke. 
Tiible-driven  scripts  and  associated 
attributes  make  it  easy  to  add 
user  types  and  tailor  their  names 
and  definitions.  You  can  assign  user- 
ype  privileges  to  team  members 
on  a  project-by-project  basis. 


.ccommodating  Your 
Aganization  s  Phases  of 
.'eveiODment 

The  ADC /Pro  Process  Manager 
provides  the  framework  for  any 
number  of  development  phases. 
By  editing  the  Process  Manager 
script  tables,  you  can  set  up  the 
phases  to  match  your  software 
development  process.  You  can  add, 
skip,  or  rename  phases,  as  desired. 


.-.utomated  Version  ./amine  lor 
Easy  file  Manaeement 

The  ADC /Pro  Process  Manager 
administers  version  naming  con¬ 
ventions  for  easy  file  management. 
Based  on  these  conventions, 

ADC /Pro  names  new  versions  to 
capture  internal  milestones,  phases 
of  development,  and  branches.  This 
history-controlled  process  is  flexible 
enough  to  handle  any  project  and 
release  naming  preferences,  while 
promoting  a  clean  file  structure. 


Controllable  Hacking  Criteria 
ADC /Pro's  power  lies  in  its  unique 
ability  to  recognize  code  based  on 
attributes  and  relationships.  You 
can  populate  and  maintain  the 
tables  of  allowable  attributes  and 
relationships  to  structure  how 
your  teams  apply  these  logical 
characteristics.  This  feature  of 
ADC /Pro  maximizes  consistency 


projectname_optional-branch_vl.2.3 
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►  You  define  the  naming  conventions  that  ADCjPro  automatically  applies  to  nezo  versions.  When  you 
move  a  version  to  the  next  phase,  ADC/Pro  automatically  changes  the  character  in  the  version  name 
(the  V  in  the  default  naming  convention  above)  that  specifies  the  phase.  Moreover,  if  you  merge  tzoo 
branches  of  a  version  —  xl.23  and  custom __xl. 2.1  —  into  a  single  development  path,  ADC/Pro  sup¬ 
plies  two  possible  names  —  x.1.2.4  and  ciisto7n_xl.2.2  — •  and  allows  you  to  select  the  name  you  prefer. 


and  avoids  problems  associated 
with  the  proliferation  of  tracking 
criteria. 

L'niimiteci  exicliitv  — 

Ultimate  c  ::ii:v 

The  Process  Manager  can  meet 
your  every  requirement.  You  can 
modify  the  Process  Manager 
scripts  by  editing  internal  tables, 
or  you  can  build  entirely  new 
scripts,  as  desired.  To  accomplish 
advanced  modifications  more 
quickly  and  confidently,  take 
advantage  of  True  Software's 
training  programs  or  Engineering 
&  Consulting  Services  support. 

Like  all  of  ADC /Pro,  the  Process 
Manager  is  platform  independent, 
so  your  scripts  are  highly  portable; 
the  same  interface  will  run  with¬ 
out  modification  in  any  supported 
environment  to  ensure  smooth 
operation  across  heterogeneous 
hardware  and  operating  systems. 
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Sophisticated  software  engineers 
recognize  that  true  software 
configuration  management  (SCM) 
requires  more  than  a  new  tool  — 
that  it  must  resoK'e  methods  of 
coordination  between  everyone  on 
the  project  team.  Experienced 
developers  want  more  than  a 
tracking  application  —  they  want 
fast  implementation  of  a  complete 
SCM  solution.  They  demand 
unexcelled  professional  services  to 
support  this  implementation. 

True  Software^^  Professional  Services 
give  you  direct  access  to  a  wealth  of 
knowledge  in  Aide-de-Camp'''‘''^/Pro, 
SCM  theory  and  practice,  industry- 
specific  applications,  and  software 
development.  By  combining  True 
Software  Professional  Services  with 
Aide-de-Camp(ADC'^'^)/Pro,  you 
achieve  an  even  faster,  smoother 
implementation  than  you  could 
on  your  own.  As  a  result,  you  will 
see  an  immediate  improvement  in 
team  management,  product  quality, 
delivery  times,  and  cost  savings. 

True  Software  Professional 
Services  deliver  more  than  piece¬ 
meal  products;  we  offer  a  suite  of 


flexible,  coordinated  services.  Our 
team  of  technical  support,  train¬ 
ing,  and  engineering  &:  consulting 
services  work  in  concert  to  ensure 
that  you  profit  from  a  total  SCM 
solution.  Choose  from  this  suite  of 
professional  services  to  launch  a 
tailored  support  program  that  will 
meet  your  specific  implementa¬ 
tion  requirements  and  timetable. 

True  Software  Engineering  & 
Consulting  Services 

When  you  elect  to  implement  True 
Software  strategic  solutions,  you 
are  committing  to  improve  your 
current  software  development 
process.  Our  engineers  immedi¬ 
ately  apply  the  strengths  of  True 
Software  products  to  your  devel¬ 
opment  environment.  They  serve 
as  teachers  and  mentors,  giving 
your  staff  easy  access  to  targeted 
support  and  advanced  techniques. 
Engineering  &  Consulting 
Services  include  a  wide  range  of 
options. 

The  Jump-Start  Program  is  the 
best  way  to  get  your  organization 
up  and  running  with  ADC /Pro. 

A  dedicated  True  Software  consul- 


tant  works  with  you  to  establish 
and  document  system  and  SCM 
Operations,  the  roll-out  process, 
and  longer-term  plans.  The  Jump- 
Start  Propram  will  prove  invalu¬ 
able  as  vou  realize  the  benefits  of 
our  SCM  technology  immediately 
after  purchasing  ADC/Pro. 

Companies  that  are  considering  — 
or  committed  to  —  the  transition 
to  ADC /Pro  can  take  advantage 
oi  Planning  for  Migration  to 
Aide-de-Camp/Pro.  As  part  of  this 
program,  a  True  Software  consultant 
synthesizes  extensive  knowledge  of 
best  SCM  practices  and  ADC/Pro, 
along  with  research  into  your 
company's  existing  software 
^evelopment  processes.  The 
resulting  migration  plan  provides 
comprehensive  documentation  that 
will  enable  you  to  efficiently 
migrate  to  an  ADC /Pro  environment. 

Whether  or  not  you  have  selected 
ADC /Pro  as  your  SCM  solution, 
you  can  benefit  from  True 
Software's  Building  a  Software 
Development  Process  program. 
Through  in-depth  interviews  with 
engineers,  project  leaders,  and 
managers,  an  SCM-savvy  consul¬ 
tant  will  formulate  and  refine  a 
tailored  software  development 
process.  You  will  receive  a  software 
standards  manual  delineating 
revery  aspect  of  the  software 
development  process  that  wTll  best 
fit  your  organization.  An  option  to 
this  program  includes  on-site 


implementation  of  the  documented 
SCM  process. 

For  organizations  that  already 
have  an  SCM  process  in  place. 

True  Software's  Assessing  your 
SCM  Process  will  evaluate  its 
effectiveness.  The  resulting 
manuscript  highlights  existing 
strengths,  identifies  weak  areas, 
recommends  improvements,  and 
offers  new  solutions. 

True  Software  consultants  can 
tailor  ADC /Pro  to  meet  the  needs 
of  any  SCM  process  with  the 
Customizmg  Aide-de-Camp/Pro 
program.  They  can  also  work  with 
your  organization  to  integrate 
ADC /Pro  with  your  existing 
development  environment, 
including  other  software  tools. 

True  Software  Training 
True  Software  Professional  Services 
offer  dedicated  training  for  every 
ADC /Pro  user,  including  devel¬ 
opers,  project  leaders,  and 
SCM/system  administrators. 
While  standard  courses  provide  a 
cost-effective  means  to  build  suc¬ 
cess  into  an  organization's  SCM 
system  implementation,  on-site 
courses  offer  customized  training 
around  any  required  focus.  We 
have  designed  our  training 
courses  so  that  any  organization 
can  apply  ADC /Pro  quickly  and 
easily,  deriving  the  benefits  of  the 
only  object-based  SCM  solution 
available  today. 


True  Software  Technical  Support 

As  a  True  Software  Technical 
Support  customer,  you  benefit 
directly  from  future  releases, 
documentation  updates,  and 
telephone  access  to  ADC /Pro 
technical  advice  and  problem 
resolution.  With  ADC /Pro  and 
SCM  expertise  at  your  fingertips, 
you  can  make  the  most  efficient 
use  of  ADC /Pro  —  to  achieve  an 
SCM  solution  that  truly  delivers. 

Working  With  the  Experts 
No  matter  what  True  Software 
Professional  Services  you  choose, 
you  can  count  on  working  with 
full-time,  dedicated  experts  who 
truly  understand  software 
development,  the  ADC /Pro  line, 
and  your  need  for  a  complete 
SCM  solution  that  will  satisfy  the 
most  demanding  requirements  for 
excellence. 
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Are  you  deluged  with  the 
BUREAUCRACY  OF  TRACKING  DOWN 
LOST  FILES  AND  OBSCURE  DELTAS? 

Do  HOURS  OF  UNRECOVERABLE  TIME 
WASH  AWAY  AS  YOU  TRY  TO  UNDER¬ 
STAND  THE  PURPOSE  OR  SOURCE  OF  A 
PARTICULAR  CHANGE? 

How  OFTEN  ARE  YOUR  OWN  BRILLIANT 
TRAINS  OF  THOUGHT  DROWNED 
^UT  BY  THE  TEDIOUS  MECHANICS  OF 
VERSIONING? 

Now,  WITH  True  Software™'s 
Aide-de-Camp'“/Pro,  you  can  take 
the  logical  approach  to  software 
configurahon  management. 
Aide-de-Camp  (ADC”‘)/Pro 
CHANGE  sets  GIVES  YOU  A  CRYSTAL- 
CLEAR  PERSPECTIVE  ON  CHANGE 
WITHIN  YOUR  SOFTWARE,  ALLOWING 
YOU  TO  MANAGE,  TRACK,  AND  CONTROL 
THE  ENTIRE  SOFTWARE  DEVELOPMENT 
PROCESS.  Start  relying  on  the 
INTELLIGENCE  OF  ADC /PRO 
CHANGE  SETS  AND  SAIL  THROUGH  THE 
COMPLEXITIES  OF  MANAGING  CHANGE. 
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The  Power  of  Change  Set 
Technology  Comes  to  Light 

ADC/Pro  is  the  only  software 
configuration  management  (SCM) 
solution  to  support  change  sets. 
Our  patent-pending,  object-based 
change  set  technology  allows  you 
to  focus  on  the  functional  changes 
required  to  meet  ever-shifting 
market  and  technical  requirements. 

Change  sets  work  the  way  you  do. 
Each  change  set  embodies  a 
particular  new  function  or  feature. 
Before  you  begin  working  with  your 
files,  you  designate  the  purpose  of 
the  task  at  hand:  perhaps  a  bug 
fix  or  an  enhancement  or  a  new 
feature.  As  you  check  out  files  and 
make  edits,  ADC/Pro  captures 
every  one  of  your  modifications, 
across  any  number  of  files,  as  part 
of  the  single  change  set. 


Change  sets  accommodate  more 
than  individual  edits.  They 
capture  and  maintain  a  wealth  of 
information  about  your  software 
system.  This  information  gives 
you  an  easy,  reliable  way  to  audit 
changes,  versions,  and  releases. 

ADC /Pro  change  sets  give  you 
access  to  any  previous  state  of 
your  software.  When  you  select  a 
version,  ADC/Pro  brings  up  the 
files  as  they  existed  based  on  the 
definitions  of  the  change  sets 
within  that  version.  You  can  query 
any  line  of  code  to  ascertain  the 
change  set  that  implements  the 
code,  including  the  author  and 
reason  for  the  change. 

Change  sets  also  guarantee  a  clear 
audit  trail  of  every  change  made 
by  every  developer  on  the  project. 
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Aide-de-Camp/Pro  is  the  oidy  SCM 
solution  to  support  true  change  migration. 


Change  set  3 
Description:  bug  fix 
Ref.ID:  SPR.3061 
^Changes  files:  mainx, 
datesx,  stringsx 
Abstract:  Customization 
tixes  display  of  date 
Tags:  BellCo  windowing, 
customizations 
Links:  file  strings,  doc 
documents  strings,  c, 
procedure  get_date  calls 
procedure  get_year 
Author:  KGS 
Created:  10/07/95  10:37 
Check  in:  10/25/95  17:26 


The  ADC/Pro  repository  contains 
versions,  change  sets,  and  files.  Each  version 
identifies  the  change  sets  that  implement  its 
functions.  Each  change  set  identifies  the 
purpose  of  the  chaiige,  the  files  it  affects,  and 
any  user-  and  softzoarc-specified  attributes. 
Each  file  contains  all  the  edits  ever  made  over 
the  life  of  the  file.  ADC/Pro  displays 
(and  activates)  or  hides  (precludes)  each  line, 
depending  on  the  change  sets  that  are  in  effect. 


Teams  can  work  in  parallel  on 
multiple  branches,  can  implement 
concurrent  development  practices, 
and  can  make  major  revisions  — 
all  without  fear  of  burning  bridges 
behind  them. 


ADC /Pro  change  set  technology 
gives  you  the  power  to  manage 
complex  parallel  development  — 
with  unparalleled  ease.  Only  with 
Aide-de-Camp/Pro,  can  teams 
effortlessly: 

•  Merge  two  separate  develop 
branches  into  one 

•  Migrate  designated  changes 
from  one  version  to  another 

•  Selectively  back  out  particular 
bug  fixes  or  features 


The  Sky's  the  Limit... 

As  an  experienced  developer, 
you  know  that  other  SCM  tools 
limit  you  with  mere  file  and 
version  administration.  They  leave 
you  inundated  with  the  complexities 
of  file  and  delta  tracking.  Set  your 
sights  on  ADC /Pro's  logical  change 
set  technology.  With  ADC /Pro, 
the  sky's  the  limit. 


I 


ADC /Pro  is  the  only  SCM  solution 
to  illuminate  your  development  path 
with  a  simple,  logical  approach  to 
incorporating  or  excluding  specific 
functional  changes. 
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Logical  software 

configuration 

management 

for  the  sophisticated 

developer 


Aide-de-Camp™/Pro  gives  soft¬ 
ware  engineers  an  intuitive  wav  to 
manage  change.  More  than  a 
tracking  tool,  Aide-de-Camp 
(ADC™) /Pro  delivers  a  client/ 
server  architecture  that  allows  vou 
to  control,  track,  and  understand 
the  software  development  changes 
you  deal  with  every  day. 

ADC/ Pro  captures  the  underlying 
purpose  and  function  of  each  code 
change  using  patent-pending, 
object-based  change  sets.  Each 
change  set  includes  the  physical 


changes  across  multiple  files  plus 
the  logical  characteristics  of  the 
changes:  their  purpose,  their 
relationships  to  other  code,  their 
attributes,  and  even  their  details 
(author,  time  stamps,  etc.). 

ADC /Pro  change  sets  empower 
you  to  define,  track,  and  control 
changes  with  ease;  you  can  even 
migrate  specific  changes  from  one 
branch  of  software  to  any  other. 

ADC/Pro  takes  advantage  of  client/ 
server  technologies  that  enable  you 
to  work  in  the  context  of  platform- 
independent, 
heterogeneous 
development  net¬ 
works.  Tire  AlX/Pro 
environment 
offers  intelligent 
repository  and 
workspace  man¬ 
agement,  a 
predefined  Process  Manager,  and 
a  comprehensive  client-based  user 
interface,  all  of  which  are  cus¬ 
tomizable  to  suit  your  particular 
software  development  process. 


Graphical  user  interface 

•  X/ Motif  C  code 

•  ADC/Pro  command  set 

•  Front-end  Process  Manager  scripts 

Command  line  interface 

•  ADC/Pro  scripting  language 

'  Front-end  Process  Manager  scripts 


►  Back-end  Process  Manager  scripts 
*  A  DC /Pro  scripting  language  extended 
with  Repository  Manager  API 
»  Repository  Manager 


The  clientlserver  architecture  of 
ADCjPro  allows  users  anywhere  on  the  nct- 
ivork  to  take  advantage  of  ADC /Pro  reposito- 
ry  and  workspace  management,  the  Process 
Manager,  and  the  graphical  and  command¬ 
line  interfaces. 
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Guaranteed  Integrity:  Repository 
and  Workspace  Management 

ADC /Pro  intelligently  manages 
the  repository,  reference  area,  and 
private  workspaces  to  ensure  that 
^ou  work  on  the  correct  files  as  they 
operate  within  the  correct  state  of 
the  software  project  as  a  whole. 


The  object-based  ADC /Pro  repos¬ 
itory  particularly  suits  incremental 
software  development.  Each 
repository  holds  all  the  develop¬ 
ment  work  pertaining  to  a  partic¬ 
ular  software  system  —  for  example, 
a  window  manager,  data  converter, 
or  communication  module.  Each 
repository  manages  the  changing 
versions  of  the  software  system 
while  optimizing  storage  security 
and  space.  Each  repository  contains: 

•  All  the  change  sets  made  to  the 
^  system,  each  of  which  includes 
f  the  names  of  the  files  that  were 
edited  to  implement  the  change, 
plus  any  number  of  logical 
characteristics 


•  A  single  copy  of  every  file  in  the 
software  system,  each  of  which 
contains  all  the  changes  made  to 
the  file  over  the  life  of  the  system 

•  All  the  versions  of  the  system, 
each  of  which  identifies  its 
parent  version  and  its  change  sets 

ADC /Pro  generates  and  manages 
private  user  workspaces  and  a 
reference  area  —  outside  the 
repository  in  the  file  system  — 
that  mirror  the  versions  of  the 
software  systems  in  the  repository. 
When  you  work  on  a  particular 
version  of  a  software  system, 
ADC/Pro  automatically  presents 
the  version  as  a  whole  —  including 
its  files,  attributes,  and  relationships 
—  in  the  correct  state  for  that 
version.  You  have  instant  access 
to  the  most  up-to-date  status  of 
the  software  system  for  any 
version  in  the  repository. 

Tailored  Control: 

The  ADC/Pro  Process  Manager 

The  AEXZ/Pro  environment  includes 


a  fully  defined,  customizable 
Process  iManager  that  gives  vour 
organization  the  power  to  manage 
your  software  development 
process  exactly  the  way  you  want. 
As  you  work  with  source  code 
and  other  files,  the  Process 
Manager  guides  you.  The  Process 
Manager  regulates  all  ADC/Pro 
operations,  including  checkin  and 
checkout,  migration  and  merging, 
and  reference-area  updates. 

Ease  of  Use:  Graphical  and 
Command-Line  Interfaces 

With  ADC /Pro,  all  members  of 
your  project  team  can  work  the 
way  they  like.  While  the  graphical 
user  interface  simplifies  the  most 
challenging  ADC /Pro  functions 

—  including  change  migration, 
merging,  and  conflict  resolution 

—  the  command-line  interface 
places  even  the  most  arcane 
ADC /Pro  functions  in  the  hands 
of  your  power  users.  Both  user  in¬ 
terfaces  are  platform  independent; 
they  run  identically,  regardless  of 
the  underlying  operating  system. 
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PLATFORMS:  Cost  Care  is  using  Aide-de-Camp/Pro 
(ADC/Pro)  on  Digital/Open  VMS  and  Digital/UNIX  plat¬ 
forms. 

FUNCTIONALITY:  Cost  Care  purchased  ADC/Pro 
as  a  part  of  its  overall  Software  Quality  Assurance  efforts. 
At  Cost  Care,  the  goal  was  twofold:  to  focus  on  improving 
software  quality  for  our  legacy  applications  and  to  manage 
the  next  generation  client/server  application  development. 
ADC/Pro's  ability  to  do  dependency  linking,  its  support  of 
concurrent  development,  and  its  powerful  merge  and  mi¬ 
gration  capabilities  were  critical  components  in  Cost  Care's 
selection  process. 

As  Cost  Care  had  no  formal  configuration  management 
process  in  place,  ADC/Pro’s  “out-of-the-box'"  Process  Man¬ 
ager  represented  a  good  starting  point  that  will  be  adapted 
to  Cost  Care's  environment  over  time.  ADC/Pro  is  a  con¬ 
figuration  management  system  for  all  programming  lan¬ 
guages,  extended  by  language-specific  scanners  for  C,  C++, 
COBOL,  FORTRAN  and  Ada  code:  the  COBOL  scanner, 
and  the  ability  to  customize  it,  was  of  particular  importance 
to  Cost  Care. 

STRENGTHS:  ACD/PRO's  ability  to  migrate 
discrete  changes  gives  it  unprecedented  capabilities  to 
support  team  development  and  fully  integrated  change 
management.  Cost  Care  developers  can  manage  projects 
on  multiple  platforms,  establish  baselines,  identify  all  the 
changes  that  implement  a  particular  feature  or  bug  fix. 


migrate  discrete  cnanges  from  different  development 
paths,  detect  physical  conflict,  and  retrieve  and  build  any 
’.  ersion  of  the  vortware. 

ADC/Pro's  tlexible  development  environment  and  its 
ability  to  manage  change  logically  are  key  strengths,  as  is 
its  customizability.  And  True  Software's  excellent  support — 
both  pre-  and  post-sale — is  a  real  strength. 

WEAKNESSES:  While  ADC/Pro  supports  a  wide  va¬ 
riety  of  platforms,  it  would  benefit  from  support  of  Win¬ 
dows  3.1,  Windows  95  and  Windows  NT,  which  is  forth¬ 
coming  in  1996. 

PRODUCT  CHARACTERISTICS:  Cost  Care  is  re¬ 
alizing  its  greatest  benefit  through  automatic  dependency 
linking  and  automation  of  the  merge/migration  process.  The 
system  administrator — with  no  prior  software  configura¬ 
tion  management  experience  and  limited  experience  with 
the  Digital  operating  systems  environments — was  able  to 
get  ADC/Pro  up  and  running,  evaluate  it,  and  put  it  into  a 
production  environment  in  just  a  few  months. 

SELECTION  CRITERIA:  Cost  Care  had  several  key 
requirements.  The  first  was  cross-platform  support  of  both 
the  Open  VMS  and  UNIX  environments.  ADC/Pro  does  this 
seamlessly.  The  second,  because  of  Cost  Care's  develop¬ 
ment  environment,  was  the  ability  to  perform  change  mi¬ 
gration — to  migrate  discrete  changes  both  forward  and 
backward  among  versions  and  releases.  ADC/Pro's  migra¬ 
tion  capability  is  unique  in  the  industry.  ADC/Pro's  Pro¬ 
cess  Manager  allowed  Cost  Care  to  get  started  with  a  pro¬ 
cess  immediately,  but  gives  us  the  flexibility  to  modify  the 
process  as  we  move  forward.  Finally,  our  trust  in  True 
Software's  support  and  communications  was  a  very  critical 
piece  of  the  selection  decision. 

VENDOR  SUPPORT:  One  word  sums  it  up — out¬ 
standing!  True  Software  provides  customers  with  a  full  suite 
of  professional  services  including  consulting,  integration 
services,  and  a  complete  training  curriculum,  as  well  as  hot 
line  and  on-site  support.  True  Software  was  very  respon¬ 
sive — both  on  the  phone  and  on  site — to  any  problems  or 
questions  we  had  during  the  evaluation  process  during  and 
after  implementation.  The  expertise  of  their  people  is  first- 
rate,  as  is  their  level  of  support  and  their  commitment. 
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TRUE  SOFTWARE:  THE  LOGICAL  APPROACH  TO 
SOFTWARE  CONFIGURATION  MANAGEMENT 

True  Software  Inc.  offers  logical  software  configu¬ 
ration  management  (SCM)  solutions  to  companies 
that  recognize  they  need  more  than  file  versioning 
and  release  management.  We  have  established  a 
reliable  reputation  worldwide,  delivering  software 
and  services  that  shorten  time  to  market,  reduce 
costs,  and  improve  quality. 

We  have  been  consulting  in  software  configuration 
management  for  over  ten  years.  We  have  evolved 
A  DC/Pro  from  an  adjunct  to  consultation  into  a  flag¬ 
ship  product.  A.y  software  developers  ourselves,  we 
take  advantage  of  A  DC/ Pro  to  produce  high-quality, 
leading  edge  software  within  an  ever-changing,  tech¬ 
no  lo  gy -driven  enviro n men t. 

True  Software  customers  are  experienced  software 
development  organizations  who  have  selected  ADC/ 
Pro  because  it  both  accommodates  and  accelerates 
their  unique  software  development  processes.  These 
sophisticated  customers  remain  loyal  to  the  ACD/Pro 
solution  because  it  is  the  logical  choice  for  their 
business  and  technical  needs. 

Founded  in  1981  as  Software  Maintenance  and 
Development  Systems,  Inc.,  in  1995  the  company 
changed  its  name  to  True  Software  Inc. 
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The  Open  Enterprise  Management  Company 


Manage  Software  Changes  and  the 
Application  Development  Process 


When  building  large,  distributed  application 
systems,  the  ability  of  your  staff  to  track  and 
manage  change  during  the  development  lifecycle 
can  mean  the  difference  between  a  successful 
project  and  pandemonium.  Today's  development 
teams  often  work  from  heterogeneous  platforms 
at  remote  locations,  and  simultaneously  make 
changes  to  a  multitude  of  interrelated  software 
modules  and  system  documentation. 

The  only  way  to  effectively  keep  track  of  this 
kind  of  complex  activity  is  with  a  comprehensive, 
repository-based  change  and  configuration 
management  (CM)  solution.  Relying  on  manual 
methods  or  unsophisticated  file  control  systems 
just  doesn't  allow  you  to  meet  the  challenges  of 
enterprise-wide  application  development. 

PLATINUM  CCC/Harvest  enables  you  to 
synchronize  development  activities  across 
heterogeneous  platforms,  throughout  your 
enterprise,  during  the  entire  A/D  lifecycle. 
CCC/Harvest  can  scale  up  to  serve  project  teams 
working  on  your  largest  enterprise  systems  or 
scale  down  to  meet  the  needs  of  your  smallest 
teams.  There's  no  need  to  expend  additional 
resources  mixing  and  matching  tools  and  then 
training  developers  to  use  a  hodgepodge  of 
platform-dependent  CM  tools — CCC/Harvest 
provides  a  single,  enterprise-wide  CM  solution. 

Keep  Your  Production 
Applications  Operational 
with  Automated  Change 
IX/ligration 

Production-oriented  development  environments 
are  geared  toward  keeping  existing  applications 
operational.  Typically,  there  is  a  constant  flow 
of  "small"  changes  to  the  production  version. 


Changes  are  continually  incorporated  as  they 
are  completed,  so  that  new  features  and  new 
information  can  be  made  available  to  users. 
CCC/Harvest  provides  a  centralized  management 
point  for  streamlining  and  coordinating  software 
change  processes  throughout  your  distributed 
environment.  It  tracks  and  "packages"  application 
components  in  practically  any  format,  including 
source,  binaries,  bitmaps,  documents,  and  more. 
These  components  can  ait  be  logically  centralized 
and  controlled,  regardless  of  their  origin. 

By  automating  the  introduction  of  changes  and 
then  streamlining  their  migration  into  production, 
CCC/Harvest  prevents  your  production  application 
from  being  contaminated  with  undesired  changes. 
As  a  result,  CCC/Harvest  eliminates  development 
crises  and  ensures  a  smooth  transition  between 
development  lifecycle  stages. 

Automate  the  Applioation 
Development  Process 

Traditional  CM  tools  make  assumptions  about 
how  your  organization  works.  They  force  you 
into  using  a  proprietary  methodology,  and  require 
programming  resources  for  any  modification. 

With  CCC/Harvest,  you  can  continue  to  do 
business  the  way  you're  accustomed  to  doing  it. 
CCC/Harvest  enables  you  to  create  or  modify 
a  model  of  your  own  development  processes 
through  simple  point-and-click  operations.  It  then 
uses  your  model  to  keep  software  changes  under 
control,  development  schedules  on  track,  and 
everyone  up  to  date.  By  automating  the  workflow, 
many  of  the  routine  tasks  of  application  develop¬ 
ment  are  also  automated,  including  notifications, 
approvals,  and  migrations  of  changes  from  one 
stage  to  another. 


^^CC/Harvest 
ensures  that  only 
approved  changeSr 
and  all  necessary 
components  are 
migrated  into  production. 
Changes  are  grouped 
by  "package" providing 
excellent  visibility  and 
control.  In  this  example, 
test  staff  see  only  those 
changes  associated 
with  packages  that 
have  been  promoted 
into  the  test  state. 


Stay  in  Syno  with 
Automated  Support  for 
Concurrent  Development 

CCC/Harvest  provides  you  with  the  option  to 
select  concurrent  development  for  a  project 
through  a  simple  setup  procedure.  If  you  choose 
concurrent  development,  you  are  assured  that 
one  developer  cannot  overwrite  another 
developer's  changes.  CCC/Harvest  automatically 
Isolates  changes  into  separate  sets.  Participating 
developers  can  be  automatically  notified  when¬ 
ever  concurrent  development  takes  place,  and 
reports  can  be  easily  generated  to  show  what 
changed,  why  the  changes  were  made,  who 
made  them,  and  when.  Combining  the  changes  of 
all  concurrent  developers  is  simplified  by  the  inte¬ 
grated  merge  facility,  which  enables  you  to  view 
and  resolve  any  conflicts  among  versions. 

Manage  in-house 
Changes  to  Vendor  Code 

CCC/Harvest  enables  you  to  do  in-house 
modifications  to  third-party  software,  and 
retrofit  those  changes  seamlessly  into  subse¬ 
quent  releases  from  the  vendor.  Differences 
between  vendor  and  in-house  releases  are 
easily  determined  and  maintained  without 
physical  duplication.  Changes  go  into  production 
only  as  they  are  certified,  and  the  original  release 
is  never  lost. 


Manage  Parallel 
Development  Activities 

If  you  need  to  maintain  multiple  releases  of 
the  same  application,  CCC/Harvest  provides 
you  with  the  tools  you  need  to  manage  parallel 
development.  For  example,  you  can  easily  create 
an  "environment"  for  emergency  maintenance, 
and  keep  those  changes  separate  from  any 
ongoing  changes  made  in  another  release.  The 
integrated  merge  facility  enables  you  to  automate 
the  merging  of  some  or  all  of  those  changes  into 
a  subsequent  development  process,  eliminating 
labor-intensive  manual  merges.  Both  short  and 
long-term  projects  can  be  developed  simultane¬ 
ously  without  inadvertently  affecting  one  another. 

Customize  CCC/Harvest 
to  Meet  Your  IMeeds 

CCC/Harvest  can  easily  adapt  to  your  company's 
standards,  requirements,  and  procedures.  Its 
solutions-oriented  structure  addresses  the  most 
common  requirements  of  development  organiza¬ 
tions  today.  CCC/Harvest  provides  an  open 
architecture  and  customization  options  that 
enable  you  to  completely  tailor  your  CM  solutions. 
The  Forms  Customization  Package  (FCP)  enables 
you  to  modify  the  problem  tracking  features  of 
CCC/Harvest.  The  Software  Integration  Kit  (SIK) 
enables  you  to  integrate  your  software  develop¬ 
ment  environment  (construction  tools,  including 
Visual  Basic  and  PowerBuilder,  testing  tools, 
other  methodologies,  help  desk,  etc.)  into 
CCC/Harvest 
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^^ombining  changes 
from  concurrent  or 
parallel  development 
is  simplified  by  using 
the  integrated  merge 
facility  in  CCC/Harvest. 


Benefit  from 
Comprefiensive 
Configuretion  iVlenagement 

Version  control 
Release  management 

Concurrent  and  parallel  development  support 
Interactive  merge 
Reusable  component  management 
Emergency  maintenance  management 
Vendor  code  management 


Automate  Software 
Processes 

Flexible  lifecycle  modeling 

Project  status  information 

Automatic  notification 

Online  approvals 

Automatic  change  migration 

Process  metric  reports 

Trade  Problems 

■  User-definable  forms 

■  Problem  forms  linked  to  actual  changes 


A/lanage  Obange  an 
Client/Server  Environments 

■  Consistent  interface  on  a  wide  range 
of  platforms 

■  Central  management  point 

m  Support  for  distributed  development 

■  PIstform-independent  security 

■  Open  architecture 

Gain  End-to-Endl  Change 
IVIanagement  Support 

CCC/Harvest  works  seamlessly  with  other  tools  in  your 
environment,  such  as  PLATINUM  Process  Continuum 
(methods-driven  process  and  project  management 
suite),  PLATINUM  Apriori  (comprehensive  help  desk 
solutions),  PLATINUM  AutoXfer  (electronic  software 
distribution),  and  most  third-party  tools.  Together, 
CCC/Harvest,  Apriori,  and  AutoXfer  comprise  an  end- 
to-end  change  management  suite  that  supports  soft¬ 
ware  development,  from  initial  request  to  deployment. 

Receive  Professional 
Services  and  Support 
Every  Step  of  the  Way 

At  PLATINUM,  we  are  committed  to  providing 
professional  consulting  services  and  support  to 
help  you  before,  during,  and  after  implementation 
of  all  your  PLATINUM  products. 

PLATINUM  Solutions,  Inc.,  our  professional 
services  division,  provides  consulting  and 
integration  services  in  five  areas  of  expertise: 

Application  Lifecycle 

Systems  Management 

Data  Warehousing 

Database  Management 

Business  Intelligence 

These  services  cover  the  full  project  life 
cycle,  including  needs  analysis,  requirements 
study,  architecture  definition,  business 
and  technical  design,  product  evaluation, 
product  customization,  and  installation  and 
implementation  services. 


PLATINUM  professionals  can  design  and 
implement  a  complete  project  or  augment 
your  in-house  staff.  And  comprehensive  training 
services  are  provided  to  ensure  full  knowledge 
transfer  at  project  completion. 


With  :PLATaSMUIVI  CCC/HARVEST,  you  can... 
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CCC/Harvest  provides  true  interoperability  across  diverse  operating 


systems. 
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Its  intuitive  GUI  provides  a  consistent  workspace  for  development 

_ ^^11  distributed  throughout  the  enterprise,  no  matter  what  platforms 

I  they  work  on. 
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automatically  related  back  to  the  original  problems  that  caused  them.  ... 

CCC/Harvest  seamlessly  integrates  with  the  other  tools  in  your  environment,  including  problem  management  solutions  such 
as  PLATINUM  Apriori,  and  electronic  software  distribution  solutions  such  as  PLATINUM  AutoXfer,  to  provide  a  trackable 


release  mechanism  for  software  upgrades. 


Automate  your  workflow  for 
developing  applications 

Through  simple  point-and-click  operations,  CCC/Harvest  easily  models 

your  software  development  process.  Integrated  notifications,  online 

approvals,  and  customizable  reports  enable  all  groups  involved  to  see 

change  processes,  including  developers,  testers,  project  leaders,  QA 

staff,  auditors,  and  customer  support  representatives. 


Supporxeci  Platforms 

■  Servers: 

HP  9000/700  or  800 
Sun 

RS/6000 
Digital  UNIX 
Windows  NT  (201990) 

1  Clients: 

HP  9000/700  or  800 
Sun 

RS/6000 
Digital  UNIX 
Windows  3.1 
Windows  95 
Windows  NT 
OS/2 

■  Relational  Databases: 

Oracle 

ODBC-compliant  (4Q1996) 

About  PLATINUIVI  tGchnoiogy,  inc. 

Leveraging  its  expertise  in  relational  technology, 
PLATINUM  technology,  /dc.,  formed  in  1987,  provides 
open  enterprise  systems  management  solutions  for 
today's  heterogeneous  computing  environments. 
PLATINUM’S  integrated  products  and  services  span 
multiple  platforms,  operating  systems,  and  vendors 
to  increase  the  efficiency  and  interoperability  of 
information  systems  across  the  enterprise. 
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The  Open  Enterprise  Management  Company 

1815  S.  Meyers  Road 

OakbrooK  Terrace,  IL  60181 

PHONES  800-442-6861  (U.S.  and  Canada) 

'08-620-5000  (Worldwide) 

FAX  708-691-0710 

E-MAIL  .nfoS’platinum.com 
URL  ■'rrov/www.piatinum.com 

Corporate  Sales  Offices 

Alberta  lEdmonton)  403-423-4477 

Arizona  iTempe)  602-838-5259 

British  Columbia  (Vancouver)  604-682-4855 

California  (Los  Angeles)  714-228-2222 

California  (Redwood  City)  415-591-8200 

California  (San  Francisco)  415-986-0918 

Colorado  (Englewood)  303-741-1898 

Florida  (Palm  Bay!  407-728-2599 

Fiorida  (Pensacola)  904-476-7166 

Florida  (Tampa)  813-963-6963 

Georgia  (Aitanta)  770-850-1700 

Kansas  (Overland  Park)  913-451  -6995 

Manitoba  (Winnipeg)  204-453-1913 

Massacnusetts  (Norwe(l)  617-982-81 1 1 

Massachusetts  (Reading)  617-944-2326 

Massacnusens  (Waltham)  617-891-6500 

Michigan  (Bloomfield  Hills)  810-645-8818 

Minnesota  (Eagen)  612-688-3033 

Missouri  (St.  Louis)  314-984-6826 

New  Jersey  (iselini  908-632-2510 

New  York  (New  York)  212-370-7160 

New  York  (Rochester)  716-425-9690 

Ohio  (Cincinnati)  513-792-2273 

Ohio  (Columbus)  614-460-3540 

Ohio  (Hudson)  216-342-3788 

Ontario  (Mississauga)  905-896-8282 

Ontario  (Ottawa)  613-566-7047 

Ontario  (Toronto)  416-324-9000 

Oregon  (Portland)  503-293-8485 

Pennsyivania  (Blue  Bell)  215-540-2242 

Pennsylvania  (Harrisburg)  717-731-9410 

Pennsyivania  (Pittsburgh)  412-561-2666 

Pennsylvania  (Plymouth  Meeting)  610-940-6020 

Quebec  (Montreal)  514-630-5363 

Texas  (Dallas)  214-735-8020 

Utah  (Sandy)  801-256-2056 

Virginia  tGlen  Allen)  804-266-1303 

Virginia  (Reston)  703-620-6500 

Washington  (Seanie)  206-281-7574 

PLATIIMUM  G€iucation 
IMational  Sales  Office 

800-334-5284x1107 


International  Subsidiaries 
and  Affiliates 


Argentina 

Hong  Kong 

Saudi  Arabia 

Australia 

Indonesia 

Singapore 

Austria 

Israel 

Slovenia 

Belgium 

Italy 

South  Africa 

Brazil 

Japan 

Spain 

Chile 

Korea 

Sweden 

China 

Malaysia 

Switzerland 

Colombia 

Mexico 

Taiwan 

Croatia 

Netherlands 

Turkey 

Denmark 

New  Zealand 

UniteiJ  Arab  Emirates 

Finland 

Norway 

United  Kingdom 

France 

Peru 

Uruguay 

Germany 

Poland 

Venezuela 

Greece 

Russia 

The  PLATINUM  products  referenced  in  this  publication  are  trademarks  of 
PLATINUM  technology,  me.,  and  its  subsidiaries.  Names  marked  or  ®  and 
other  company  and  product  names  may  be  trademarks  or  registered  trademarks 
of  their  respective  companies. 

PLATINUM  CCC/Harvest  was  developed  by  PLATINUM'S  Santa  Barbara  Development 
Laboratory. 


©  Copyright  1996  by  PLATINUM  technology,  inc.  All  rights  reserved. 


This  brochure  is  printed  on  recycled  paper  and  is  fully  recyclable. 
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The  endangered  animal  featured  in  this  publication  symbolizes  PLATINUM'S 
commitment  to  preserving  the  earth's  environment.  To  support  this  commitment, 
the  PLATINUM  Wildlife  Foundation  has  been  established.  For  information,  call 
800-442-6861  or  send  e-mail  to  wildlife@platinum.com. 
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THE  ENTERPRISE-WIDE  CHANGE  AND 
CONFIGURATION  MANAGEMENT  SOLUTION 
FOR  CLIENT/SERVER  ENVIRONMENTS 


iVlanage  Software  Change 
and  the  Application 
development  Process 


■lanaging  enterprise-wide  application  development  projects  can  be 
xtremeiy  complex.  Changes  to  code,  design  specs,  and  documentation 
an  come  in  from  remote  project  teams  on  a  regular  basis.  PLATINUM 
XC/Harvest  simplifies  enterprise  development  by  enabling  your  teams 
0  synchronize  concurrent  and  parallel  development  across  remote 
eterogeneous  platforms.  And  it  provides  a  repository-based,  central 
nanagement  point  for  coordinating  enterprise-wide  change. 
XC/Harvest  increases  productivity,  improves  software  quality, 

^nd  accelerates  development  cycles. 

With  CCC/Harvest  you  can: 

■  Control  your  software  change  process  from  a  central 
management  point 

■  Synchronize  development  activities  across  diverse  operating 
systems  with  true  interoperability 

■  Track  all  your  changes  through  the  entire  development  and 
maintenance  lifecycle 

■  Au^ate  the  workflow  for  developing  and  maintaining  your 
^^ktions 

■  hBre  that  your  production  application  is  free  from  change 
regression  and  overwritten  changes 

■  Support  concurrent  and  parallel  development  with  an  integrated 
merge  facility 

■  Manage  in-house  changes  to  vendor  code. 


Establish  a  Systematic  Approach  for 
Managing  Software  Changes 

CCC/Harvest  organizes  related  code,  design  objects,  and  documenta¬ 
tion  into  change  "packages"  and  tracks  these  packages  through  the 
application  lifecycle.  By  using  simple  "point-and-click"  operations,  you 
can  create  or  modify  a  model  of  your  application  development  work- 
flow  that  dictates  the  stages  through  which  your  change  packages  are 
migrated.  This  feature  brings  order  to  your  development  process  by 
ensuring  that  changes  are  introduced  according  to  the  workflow  you 
define.  Many  of  the  routine  tasks  of  development  are  automated, 
including  notifications,  approvals,  and  migrations  of  changes  from  one 
stage  to  another. 


Benefit  from  Built-in  Problem  Tracking 

CCC/Harvest's  process  modeling  capability  and  customized  forms 
automate  information  gathering,  assist  in  the  management  of  problems, 
and  give  you  a  consolidated  view  of  problem  components. 


Capitalize  on  a  Three-tier  Client/Server 
Architecture 

CCC/Harvest's  flexible  three-tier  client/server  architecture  enables  you 
to  capitalize  on  today's  inexpensive,  high-powered  computing  hard¬ 
ware,  minimize  network  traffic,  and  provide  platform-independent 
security.  Plus,  with  multiple  platform  support,  CCC/Harvest  provides 
uniform  availability  of  project  data  across  heterogeneous  computing 
environments. 


Integrate  CCC/Harvest  with  Other  Tools 

CCC/Harvest  is  designed  to  easily  adapt  to  and  support  the  changing 
needs  of  your  organization.  Using  a  relational  database,  user-defined 
processes,  and  its  Software  Integration  Kit,  CCC/Harvest  works  seam¬ 
lessly  with  other  tools  in  your  environment,  such  as  PLATINUM 
Process  Continuum  (methods-driven  process  and  project  management 
suite),  PLATINUM  Apriori  (comprehensive  help  desk  solutions), 
PLATINUM  AutoXfer  (electronic  software  distribution),  and  most  third- 
party  tools.  Together,  CCC/Harvest,  Apriori,  and  AutoXfer  comprise  an 
end-to-end  change  management  suite  that  supports  software  develop¬ 
ment,  from  initial  request  to  deployment. 

Comprehensive  Configuration  Management 

■  Version  control 

■  Release  management 

■  Concurrent  and  parallel  development  support 

■  Interactive  merge 

■  Reusable  component  management 

■  Emergency  maintenance 

■  Vendor  code  management 

Software  Process  Automation 

■  Flexible  lifecycle  modeling 

■  Project  status  information 

■  Automatic  notification 

■  Online  approvals 

■  Automatic  change  migration 


Built-in  Problem  Tracking 

■  User-definable  forms 

■  Problem  report  linked  to  actual  change 

and  Open  Architecture 

■  Complete  interoperability  across  all  platforms 

■  Central  management  point 

■  Support  for  distributed  development 

■  Consistent  interface  on  a  wide  range  of  platforms 

■  Platform-independent  security 

■  Open  architecture 

Platform  Support 
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PLATINUM  CCC/Harvest 
FAX-BscIc  Form 

Fill  out  the  information  below  and  FAX  this  page  to: 

1.708.691.0718  (worldwide) 

Or  call  your  PLATINUM  sales  representative  at: 

1.800.442.6861  (U.S.  and  Canada) 

1.708.620.5000  (worldwide) 

J  Please  send  me  additional  information  about  CCC/Harvest 
Name  . JoYfitle 


Company 


Phone  FAX 


Email  Address 


CCC/Harvest  features  a  consistent  GUI  across  all  platforms. 
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The  Open  Euierphse  Manai^cnient  Company 


1815  S.  Mevers  Road 
Oakbrook  Terrace.  IL  60181 
PHONES  800-442-6861  (U.S.  and  Canadai 
708-620-5000 

EMAIL  uifo’®platinum,com 

URL  nrtp://www.plaiinum.com 
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Ph:  805-683-5777  •  Fax:  805-683-4105 


An  Overview  of  CCC/Harvest 


The  new  client/server  generation  of  the  CCC  product  family 


Introduction 


CCC/Harvest  represents  the  next  generation  in  the  evolution  of  the  CCC  product  family  from 
Softool  Corporation.  CCC/Harvest  continues  the  tradition  of  the  CCC/Manager  family.  T  .iV«» 
other  CCC  products,  it  provides  a  comprehensive  software  change  and  configuration 
management  (CM)  solution  for  the  corporate  development  environment.  However, 
CCC/Harvest  builds  on  Softool's  many  years  of  experience  in  this  field  to  address  the 
growing  needs  of  client/server  environments. 

Why  is  CCC/Harvest  Needed? 

The  computing  environment  of  the  90s  is  rapidly  becoming  more  and  more  complex.  Isolated 
data  centers  running  on  a  single  platform  and  standalone  technical  workstations  are 
becoming  environments  of  the  past.  Instead,  an  enterprise-wide  network  of  different, 
specialized  platforms  is  increasingly  common.  Such  a  heterogeneous  set  of  platforms 
supports  a  software  life  cycle  with  many  different  functional  groups,  application  domains, 
and  procedural  methodologies. 


Copyright  ©1993  Softool  Corporation — ^AII  rights  reserved 
CCC  and  Softool  are  registered  trademarks  of  Softool  Corporation. 

All  other  products  are  trademarks  or  registered  trademarks  of  their  respective  companies. 
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Cross-platform  life  cycles  have  created  a  new  set  of  challenges  for  the  software 

development/maintenance  organization.  Some  of  diese  challenges  include  the  following: 

•  Internal  procedures  and  processes  are  evolving  rapidly.  Development  tools  must  be  able 
to  adapt  to  and  support  diese  changing  processes. 

•  Client/server  applications  are  being  developed  on  multiple  platforms  and  update  cycles 
must  be  coordinated  and  tighdy  controlled. 

•  New  applications  are  being  built  relying  on  4GLs,  databases,  CASE  tools,  and  reusable 
code.  All  of  these  generate  increased  quantity  and  complexity  tiom  the  control  and 
auditing  aspect 

•  With  many  different  computing  platforms,  it  is  essential  diat  common  methodologies, 
interfaces  and-processes  presented  to  the  development  organization. 


CCC/Harvest  Features 

CCC/Harvest  has  been  designed  to  address  the  needs  of  today's  conqiuting  environment  The 
following  list  indicates  some  of  die  important  requirements  that  CCC/Harvest  satisfies: 

•  Supports  distributed  development  in  client/server  environments 

•  Provides  support  for  the  entire  developmient  and  maintenance  life  cycle 

•  Can  be  used  easily  by  all  people  in  the  software  development/maintenance  and  support 
organization 

•  Ad^ts  to  widely  diverse  corporate  software  development  and  maintenance  styles 

•  Facilitates  integration  with  other  development  tools 

•  Is  easy  to  implement 

•  Minimizes  impact  on  computing  resources  and  staff 

All  of  these  features  of  CCC/Harvest  can  be  summarized  in  six  major  categories: 
client/server  support,  an  integrated  approach,  adaptability,  openness,  ease  of  implementation, 
and  usability. 

Client/server  Support 

Client/server  computing  solutions  represent  one  of  the  fastest  growing  types  of  environments 
in  the  computer  industry  today.  These  solutions  have  increased  in  popularity  because  they 
allow  organizations  to  preserve  their  current  hardware  investments  and  still  take  advantage  of 
the  state-of-the  art  technology  provided  by  faster,  friendlier  workstations  and  PCs. 

However,  the  story  doesn't  end  when  various  diverse  hardware  platforms  have  been 
successfully  interconnected.  Moving  to  a  client/server  environment  can  have  a  significant 
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impact  on  the  software  development  and  maintenance  process.  Often,  the  old  ways  of  doing 
business  no  longer  make  sense.  New  procedures  must  be  established,  new  tools  purchased, 
and  time  and  money  spent  retraining  persoimeL 

In  fact,  the  move  to  a  client/server  architecture  can  leave  an  organization  especially 
vulnerable  to  losing  control  of  critical  software  assets.  It  is  often  diflicuit  to  determine  how 
auditing  standards  can  be  satisfied  in  such  a  dynamic  environment  This  fact  may  leave  many 
managers  wondering  if  the  client/server  relationship  is  creating  a  "black  hole"  through  which 
unwanted  changes  can  enter  the  system.  As  a  result  of  the  distribution  of  computer  resources, 
the  quality,  integrity,  and  security  of  software  can  suffer. 

CCC/Harvest  is  the  only  product  that  provides  an  integrated  CM  solution  in  client/server 
environments  with  interoperability  across  all  platforms.  Users  will  find  that  CCC/Harvest  is 
a  powerful  tool,  easy  to  in:q)lement  and  use,  that  adapts  readily  to  their  way  of  doing 
business. 


An  Integrated  Approach 

However,  client/server  support  is  not  ail  that's  different  about  CCC/Harvest  CCC/Harvest 
incorporates  a  whole  new  approach  to  software  configuration  management  in  general. 
Traditional  CM  tools  have  often  viewed  CM  as  an  isolated,  technical  fiuiction  that  can  be 
performed  off  to  the  side  of  the  main  flow  of  development  activities. 

CCC/Harvest,  on  the  other  hand,  provides  an  environment  flexible  enough  to  support  and 
integrate  many  different  kinds  of  work  processes  under  one  general  iimhmlla  This  integrated 
approach  allows  problem  tracking  to  be  unified  witii  change  fnanagp.Tn(»nt  through 
CCC/Harvest  forms.  But  any  other  kind  of  wo±  flow  that  is  associated  with  software 
development  can  be  managed  through  CCC/Harvest 

The  basic  purpose  of  CCC/Harvest  is  to  provide  a  unified  fiamework  supporting  all  the  core 
fiinctions  in  the  software  development  and  maintenance  process.  This  includes  problem 
reporting  and  tracking,  software  inventory  management  change  and  version  managffn7Pnf 
application  management  release  and  baseline  control,  support  for  parallel  and  concurrent' 
development  and  the  distribution  of  updated  software  and  related  information. 

All  functional  groups  involved  in  the  development  and  maintenance  process  can  benefit  from 
CCC/Harvest  not  just  programmers.  It  includes  extensive  management  reporting  capabilities 
and  supports  the  auditing  function. 


Adaptability 

Traditional  CM  tools  usually  made  a  lot  of  assumptions  about  how  an  organization  does  its 
work.  Users  had  to  squeeze  their  own  procedures  into  a  pre-defined  mold  that  was  often  a 
poor  match  for  their  needs.  One  of  the  most  powerful  features  of  CCC/Har\’est,  in  contrast,  is 
its  adaptability.  An  organization  can  define  and  follow  any  kind  of  software  life  cycle  and 
process  model.  Users  can  continue  to  do  business  the  way  they  are  accustomed  to. 
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Fuithermoie,  CCCTHarvest  allows  a  site  to  synchronize  development  activities  across  all 
platforms  involved  in  development,  maintenance,  and  problem  tracking  activities.  An 
organization  can  integrate  its  own  tools  and  processes  into  CCCTHarvest  and  provide 
notification  using  its  own  mail  system. 


Openness 

CCC/Harvest  is  a  client/server  application.  The  client  and  server  portions  may  both  execute 
on  the  same  machine  or  be  distributed  across  multiple  platforms.  The  client  portion  of 
CCC/Harvest  consists  of  the  gr^hical  user  interface  (GUI),  the  command  line,  and  the 
application  programming  interface  (API).  The  server  portion  contains  most  of  the  program 
logic,  inclu^g  the  delta  engine,  which  allows  CCC/Harvest  to  calculate  and  store  only  the 
differences-between  one.  version  of  a  file.and  another.  The  server  portion  also  includes  an 
SQL  layer,  w^ch  .communicates  with  a  relational  database. 

CCC/Harvest's  open  architecture  allows  easy  access  to  CM  information.  Rather  than 
developing  yet  another  database  standard,  control  information  is  stored  within  a 
commercially  available  relational  database.  CCC/Harvest  table  formats  are  fully  documented. 
Database  information  is  normally  accessed  from  the  GUL  but  a  site  may  access  the  database 
direcdy  to  generate  reports  or  integrate  with  other  development  took.  Integration  is  further 
supported  by  the  API  and  command  line. 


Ease  of  implementation 

CCC/Harvest  has  been  designed  with  ease  of  irr^lementation  and  use  as  one  of  its  highest 
ptiorides.  Softool's  consulting  group  is  available  to  assist  in  die  design  and  inqilementadon 
of  CCC/Harvest,  allowing  an  organization  to  become  operadonal  quickly  and  derive 
immffHiatft  benefits.  The  implementadon  of  CCC/Harvest  is  most  successful  vdien  built  upon 
a  solid  foundadon  that  takes  into  consideradon  company  standards,  requirememts,  processes 
and  procedures.  Once  such  a  foundadon  is  in  place,  the  tool  investment  can  be  fully 
recognized. 


Usability 

The  CCC/Harvest  user  interface  is  implemented  using  state-of-the-art  GUI  technology.  It  is 
highly  interacdve  and  has  been  designed  with  ease  of  use  and  minimized  training  dme  as 
primary  criteria.  Multicolored  icons  and  tool  bars  are  used  throughout  the  interface.  Most 
common  fiincdons  have  keyboard  accelerators  defined  for  them.  A  full  on-line,  context 
sensitive,  interactive  help  facility  is  available. 

Each  user  may  customize  the  appearance  of  the  interface.  CCC/Harvest  supports 
OSF/Modf®,  OPEN  LOOK®,  and  Microsoft®  Windows™  "look  and  feel"  across  all 
platforms.  Users  also  have  complete  control  over  fonts,  font  size,  and  color  schemes. 

CCC/Harvest's  user  interface  is  object  oriented.  Users  select  a  CCC/Harvest  object  through 
the  interface  and  then  choose  a  related  action.  Some  examples  of  CCC/Harvest  objects  are 
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views,  pnx*sses,  packages,  package  groups,  and  users.  All  of  these  objects  are 
later  in  this  document 

nie  objects  arc  represented  as  icon  buttons  or  selection  lists.  This  approach  allows  users  to 
apply  multiple  unrelated  methods  or  processes  to  individual  objects  or  groups  of  objects  from 
a  single  location,  ft  also  means  that  the  user  never  has  to  remember  the  naTn>»  of  an  object  ail 
are  available  thiDU^  lists. . — .  . -  .  - 

There  arc  two  entry  points  into  the  CCCTHarvest  GUt  the  main  window  and  the  Workbench. 


Figure  I:  The  CCC/Harvest  Main  Window 

Administrators  work  through  the  main  window  to  perform  setup  functions.  From  the  main 
window,  various  editors  are  available  that  allow  administrators  to  set  up  environments, 
define  users,  and  create  user  groups,  forms,  and  repositories. 

Developers  and  individuals  involved  with  problem  management  access  the  Workbench.  All 
of  the  objects  used  in  day-to-day  CM  activities  can  be  manipulated  through  the  Workbench 
interface. 
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Figure  2:  The  CCC/Harvest  Workbench  Viewing  Versions 


In  addition  to  the  graphical  user  interface,  a  full  application  programming  Tnfprf^^rp  is 
available.  All  important  fimcdons  that  can  be  performed  through  the  GUI  can  also  be.. 
petfonned  through  the  APL  The  command  line  interface  allows  developers  to 
frequent  functions  like  check  in  and  check  out  duectly  from  the  operating  system,  without 
having  to  invoke  the  GUL 


Basic  CCC/Harvest  Concepts 


The  use  of  CCC/Harvest  is  divided  into  "setup"  tasks  and  day-to-day  operational  tasks.  The 
setup  tasks  are  required  primarily  when  first  implementing  CCC/Harvest  Such  tasks  include 
initializing  the  physical  repository,  defining  within  CCC/Harvest  the  software  development 
and  maintenance  model  employed  by  an  organization,  and  setting  up  user  groups.  Complete 
default  environment  models  are  provided  "off  the  shelf,"  so  that  defining  a  model  may  be 
omitted.  Alternatively,  you  can  begin  with  a  default  model  and  modify  it  to  adapt  to  your 
particular  needs. 

Modification  and  maintenance  of  the  repository  and  life  cycle  may  be  needed  as 
requirements  and  environmental  factors  change.  Typically,  these  setup  activities  are  limited 
to  a  designated  administrator  of  the  CCC/Harvest  environment. 

Once  CCC/Harvest  is  set  up,  its  day-to-day  operation  is  straightforward.  Users,  based  on 
their  operating  context,  are  given  access  to  information,  provided  a  set  of  processes  that  can 
be  performed,  and  notified  of  actions  that  need  to  be  taken. 

A  number  of  closely  related  concepts  associated  witli  CCC/Harvest  provide  important 
building  blocks  in  a  life  cycle  model.  These  concepts  include  environments,  life  cycles, 
views,  processes,  packages,  package  groups,  aoA  forms.  Software  development  and 
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maintenance  models  matching  an  oiganizadon's  way  of  doing  business  are  built  with  these 
objects. 


Environments 

An  environment  is  the  control  framework  driving  the  development  and  maintenance 
process.  It  specifies  how  data  is  accessed,  the  processes  allowed  to  execute,  how  p-hang>»<f 
move  throu^  the  development  cycle,  and  user  responsibilities.  Most  CCC/Harvest 
functions  are  only  available  when  an  environment  has  been  selected. 


A  site  may  have  a  number  of  different  environments,  depending  on  the  number  of 
applications  being:controlled.and.'the-ldnd  of  development  activity  undertaken.  For  example, 
there  may  be  one  environment  for  maintaining  an  already  released  version  of  an  ^plication, 
another  for  developing  the  next  release,  and  a  third  for  maintaining  code  shared  among 
various  applications.  There  might  be  an  endiely  different  environment  used  by  the  support 
group  for  tracking  incidents  and  problems. 


Life  Cycles:  States  and  Processes 

The  life  cycle  is  the  part  of  the  environment  that  defines  a  model  for  a  particular 
development  and  maintenance  process.  This  model  reflects  the  "^ical”  way  changes  are 
made  at  a  particular  site.  The  life  cycle  describes  the  path  that  changes  take  as  development 
progresses  in  terms  of  an  ordered  set  of  phases  or  suites.  The  life  cycle  can  be  considered 
the  "heart"  of  an  enviromnent,  because  it  controls  the  flow  of  development  life  within  it 

A  life  cycle  can  include  many  or  few  states,  depending  on  each  site's  individual 
requirements.  A  common  development  scenario  might  include  states  for  assigning  change 
requests,  making  changes,  testing  changes,  integrating  changes,  and  releasing  a  completed 
product  However,  if  developers  typically  do  all  the  testing,  the  testing  phase  could  he  left 
out  CCC/Harvest  gives  you  complete  flexibility  to  defme  any  kind  of  model. 

Within  each  state,  processes  define  the  various  acti\'ities  that  can  occur.  This  means  that  each 
state  can  have  a  uniquely  defined  scope  of  work.  The  promote  and  demote  processes  have 
special  significance  in  a  life  cycle  model  because  they  determine  how  states  are  related  and 
how  changes  can  move  between  them. 

Views 


Views  define  the  kind  of  data  that  can  be  accessed  from  within  an  environment.  Each 
environment  has  one  master  view,  which  defines  the  items  to  be  operated  on.  The  items 
themselves  are  maintained  in  a  physical  repository,  which  can  be  shared  by  more  than  one 
environment  A  master  view  may  include  items  from  mote  than  one  physical  repository,  if 
needed,  as  in  the  case  of  shared  code. 
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Additional  views  can  be  created  based  on  the  master  view.  Within  a  iife  cycle,  each  state 
may  have  a  particular  view  associated  with  it  The  view  determines  which  item  versions  are 
accessible  to  users  in  that  view. 


Processes 

A  set  of  valid  processes  may  be  defined  for  each  state  in  the  life  cycle.  Processes  are 
cotnniands  that  perform  a  task.  The  processes  defined  for  a  state  determine  the  activities 
that  can  go  on  in  that  state,  or  its  scope  of  work.  Additional  actions  can  be 
each  process,  based  on  its  success  or  failure.  This  allows  commands  to  be  together  to 

perform  mote  complex  tasks. 

Processes  associated  with^state  me:  used.differently  than  those  linkftri  to  other  processes.  A 
process  associated- vidth  a  state  appears  as  an  option  available  to  the  user  on  the  Woricbench 
To  occur,  such  a  process  must  be  expUcitly  invoked  by  a  user.  Linked  processes  occur 
automaticaUy  whenever  the  process  they  are  linked  to  is  invoked. 

CCC/Harvest  comes  with  a  number  of  different  process  types  that  can  be  configured  by  an 
administrator.  In  addition,  processes  can  be  defined  that  invoke  other  user-suppUed 
programs.  This  feature  allows  the  administrator  to  integrate  the  use  of  existing  development 
tools  mto  the  Harvest  life  cycle.  The  foUowing  table  displays  a  subset  of  the  processes 
supplied  with  CCC/HarvesL 


Process  Type  • 

Action 

Approve 

Allow  electronic  sign-off  of  a  package  or  package  group  before  state  chanee 

Checkin 

Create  a  new  version  of  an  item  by  bringing  the  changes  made  to  an  operating 
system  file  into  CCC/Harvest 

Check  Out 

Copy  a  version  of  a  Harvest  item  to  an  exteamai  directory  and  optionally 
reserve  it 

Create  Package 

Create  a  package  and  form  with  die  same  name  and  automadcailv  associate 
them. 

Demote 

Return  a  package  to  a  previous  state 

Merge 

Perform  merging  of  parallel  versions 

Move  Package  ■ 

Move  a-a  package  from  a  state  in  one  environment  to  a  state  in  another 
environment 

Notify 

Send  electronic  messages  to  users  or  user  groups 

Promote 

Move  a  package  to  another  state  further  in  the  life  cycle 

User  Defined 

Process  (UDP) 

Execute  a  user  defined  process  on  the  client  machine 

The  user-defined  process  (UDP)  allows  you  to  define  any  number  of  additional  processes  to 
CCC/Harvest.  UDPs  allow  a  site  to  easily  integrate  other  tools  or  utilities  into  the  CM 
environment. 


Rgure  3  illustrates  the  life  cycle  model  of  an  environment  called  Release.  Release  has  been 
defined  with  several  states,  beginning  with  Analyze  and  ending  with  Close.  The  CHECK 
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OUT,  CHECK  IN,  BUILD,  and  PROMOTE  processes  may  take  place  within  the  Develop 
state.  These  processes  are  optional,  meaning  that  they  may  be  invoked  at  any  time  during  the 
Develop  phase  of  the  Release  life  cycle.  The  PROMOTE  process  causes  a  package  to  move 
from  one  state  to  the  next. 

Promote 


Figure  3:  The  Release  Environment  Model 

The  process  that  promotes  packages  from  the  Develop  to  the  Test  state  has  other  processes 
linVi^  to  it  These  processes  are  automatically  invoked  whenever  a  package  is  promoted.  A 
key  component  of  the  flexibility  within  CCC/Harvest  is  the  ability  to  link  processes  together 
in  a  dependent  fashion.  In  Hgure  3,  the  NOTIFY  process  linked  to  the  promote  is  defined  to 
be  invoked  only  if  the  build  process  succeeds.  If  the  BUILD  process  fails,  the  NOTIFY  and 
DEMOTE  processes  are  invoked  and  the  state  returned  to  Develop. 


Packages  and  Package  Groups 


A  package  is  the  basic  unit  of  work  that  moves  through  the  life  cycle.  It  typically  represents 
a  problem  or  an'-incident  that  needs  to  be  tracked,  the  changes  made  in  response  to  the 
problem  or  incident,  and  any  other  associated  information. 


A  package  group  provides  a  higher  logical  level  for  operating  on  related  packages.  A 
particular  package  may  belong  to  one  group  or  several,  or  it  may  not  belong  to  any.  Any 
operation  that  can  be  performed  on  a  package  can  be  performed  on  all  packages  in  a  . 
package  group.  For  example,  a  user  can  promote  all  packages  in  a  group  from  one  state  to 
the  next.  If  an  approval  is  required  before  packages  can  be  promoted,  another  user  can 
approve  the  promotion  of  the  group. 


Package  groups  can  also  be  used  as  the  basis  for  filtering  operations.  This  allows  you  to 
easily  set  up  variant  events  for  special  kinds  of  packages.  Referring  to  Figure  3,  all  packages 
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in  a  certain  group  may  need  to  pass  throu^  an  extra  state  (e.g..  Integration)  before  going  to 
the  Test  state  in  the  life  cycle. 

The  package  is  the  user's  link  to  the  actual  data  accessed  during  the  change  process.  Each 
package  must  be  within  a  particular  state  of  the  life  cycle.  Associated  with  a  state  is  a  view. 
The  view  defines  the  data  and  its  versions  accessed  by  a  package  in  that  All  packages 

in  the  same  state  share  the  same.  view. _  _ 

For  example,  consider  a  set  of  pack^  that  share  a  Development  view  of  an  application. 
Changes  made  for  each  package  sharing  the  view  are  immediately  visible  to  the  others 
sharing  the  same  view.  However,  these  same  changes  are  not  visible  from  the  Test  view  until 
the  changes  are  promoted  to  Test 


Forms 


Forms  represent  a  way  of  maintaining  and  organizing  information  within  CCC/Harvest 
Harvest  forms  can  be  used  in  much  the  same  way  that  pj^r  forms  are  used.  For  example, 
they  can  be  used  to  track  issues  and  problems  or  as  a  strucUired  method  of  communication. 


Forms  can  beaccessed  directly  from  the  CCC/Harvest  main  window  or  from  the 
Workbench.  They  do  not  belong  to  a  particular  environment  but  can  be  used  by  any.  Forms 
attain  their  greatest  usefulness  through  association  with  packages.  TTiis  association  provides'r. 
the  link  between  the  problem  tracking  and  change  tracking  functions  in  CCC/HarvesL 
Forms  can  also  be  associated  with  other  forms,  allowing  information  to  be  cross  referenced. 
For  example,  you  might  associate  a  customer  contact  form  with  a  problem  reported  by  that 
customer. 


All  the  information  gathered  through  a  form  is  also  directly  accessible  from  the  associated 
package. 

A  number  of  standard  forms  are  provided  with  CCC/Harvest,  such  as  a  problem  tracking 
form,  user  contact  form,  testing  information  form,  question  and  answer  form,  and  comment 
form.  In  addition,  custom  forms  may  be  created  that  are  tailored  to  the  specific  requirements 
of  individual  users. 


Other  Concepts 

A  number  of  other  concepts  are  important  in  completing  this  overview  of  the  CCC/Harvest 
functionality.  These  ate  discussed  in  the  following  subsections. 


User  Groups 


When  users  are  defined  to  CCC/Harvest  they  may  be  placed  in  user  groups.  User  groups 
exist  at  the  Harvest  level  and  are  available  in  all  environments  defined  in  HarvesL  A  user 
can  belong  to  any  number  of  user  groups,  and  there  is  no  hierarchy  implied  by  the  groups. 
For  example,  a  user  in  the  Development  Manager  group  does  not  implicitly  have  the 
privileges  of  users  in  the  Developer  group. 
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User  groups  provide  a  powerful,  flexible  mechanism  that  can  be  en^loyed  in  association 
with  access  control,  notification,  and  approvals. 


Access  Control 


CCC/Harvest  access  control  is  designed  to  allow  a  site  to  implement  any  level  of  access 
control  granularity  required.  The  access  control  is  based  on  &e  combination  of  user  or  user 
group,  object,  and  action.  Each  user  can  belong  to  any  number  of  groups,  and  there  is  no 
hierarchy  implied  by  the  groups. 


For  example,  using  CCC/Harvest's  access  methods,  user  group  PRODCNTL  can  be  given 
access  to  build  an  executable  program  when  a  paclcage  is  in  the  final  integration  ph^e  of  its 
life  cycle. 


Notification 

The  notification  process  is  completely  user  defined.  The  CCC/Harvest  administrator  can 
specify  what  notifications  will  be  sent,  who  will  receive  them,  and  under  what 
circumstances.  For  example,  the  QA  user  group  can  be  notified  when  a  package  is 
successfully  promoted  from  Development  to  Test  or  the  Project  Leader  notified  when  all 
approvals  for  a  package  have  been  completed. 


Approvals 

The  life  cycle  can  be  defined  so  that  certain  users  or  user  groups' must  give  their  approval 
before  a  package  can  move  forward  through  the  life  cycle  from  one  state  to  another.  Each 
state  can  have  uniquely  defined  approval  requirements. 

Until  each  of  the  specified  users  or  at  least  one  member  of  a  specified  user  group  has  given 
their  approval,  a  package  cannot  be  promoted.  The  current  set  of  outstanding  approvals  can 
be  determined  on  either  a  user,  user  group  or  package  basis. 


Developing  with  CCC/Harvest 


From  the  perspective  of  a  software  engineer,  CCC/Harvest  activity  begins  with  the  reviewing 
of  outstanding  change  requests,  or  those  specifically  assigned  to  the  individual.  The  software 
engineer  interacts  with  CCC/Har\'est  to  query  on  the  change  request  forms,  and  may  view  the 
actual  change  request  form  contents  on  the  screen.  Each  change  request  is  associated  with  a 
package.  The  package  is  used  to  group  and  manage  changes  as  they  move  through  the  life 
cycle. 
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Figure  4:  CCC/Harvest  Displays 


The  software  engineer  then  proceeds  with  the  change  activity.  For  example,  in  the  case  of 
new  development,  this  could  be  the  interaction  with  a  CASE  design  or  4GL  tool  to  create  a 
design  object  In  the  case  of  maintenance,  the  engineer  may  browse  various  modules  of 
software  to  determine  the  cause  of  failure. 


Next  the  engineer  modifies  information  through  the  standard  check  out  and  check  in 
operations  familiar  to  CCC  users,  using  the  package  associated  with  the  change  request  form. 
The  package/form  association  allows  information  about  package  changes  to  be  accessible 
ftom  the  form.  At  the  same  time  it  allows  information  about  the  change  request  and  its 
history  to  be  accessible  from  the  package. 


Changes  move  through  the  life  cycle  as  they  are  reviewed  and  approved.  CCC/Harvest 
provides'for  automated  notification  and  on-line  approvals.  These  approvals  are  integrated 
automatically  into  the  package  history. 


CCC/Harvest  Architecture 

CCCTHarvest  is  a  client/server  application  built  to  support  the  distributed  development 
environment  and  take  advantage  of  the  strengths  of  various  platforms.  It  also  allows  you  to 
automatically  synchronize  repositories  maintained  on  different  computers. 


Page  12  Technical  Note  85 


Components 

Figure  5  illustrates  the  various  components  in  the  CCC/Harvest  architecture.  The 
CCCTHarvest  client  (1)  consists  of  &e  graphical  user  interface  (GUI),  command  lini» 
interface,  and  application  programniing  interface  (API). 

The  server  (4)  contains  the  majority  of  the  CCC/Harvest  logic.  It  includes  two  major  pieces: 

•  The  delta  engine  communicates  with  the  CCC/Harvest  repository  (5).  The 
CCC/Harvest  repository  is  a  set  of  operating  system  directories  used  to  maintain 
files.  The  delta  files  contain  the  changed  lines  to  items  under  Harvest's  control 

•  The  SQL  layer  communicates  with  a  relational  database  (3)  (RDB).  The  relational 
database  is  used  to  store  detailed  information  about  items  imder  CCC/Harvest's  control. 
CCC/Harvest  uses  the  RDB  to  maintain  information  about  logical  structures  like 
packages  and  package  groups.  In  addidon,  the  RDB  maintains  control  data  describing  the 
physical  versions,  including  the  version  ID,  user,  date/time,  remarks,  and  package 
informadon. 

A  communication  layer  (2)  provides  the  connecdon  between  the  CCC/Harvest  client  and 
server.  The  client,  server,  repository,  and  reladonai  database  may  each  reside  on  different 
heterogeneous  platforms. 


(D 


CUENT 

GUI  and 
Command  Line 


Figure  5:  CCC/Harvest  Architecture 

The  communicadon  layer  consists  of  a  set  of  protocols  that  allow  the  CCC/Harvest 
components  to  work  together.  This  layer  is  not  bound  to  any  particular  network  protocol.  It  is 
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built  using  a  level  of  abstraction  on  top  of  the  low-level  communication  layer.  A  number  of 
protocols  such  as  DCE/RPC  are  supported,  as  well  as  basic  communication  mechanisms  like 
sockets. 

Requests  by  the  client  are  queued  and  processed  serially.  However,  the  architecture  of 
CCC/Harvest  supports  the  existence  of  multiple  server  processes  to  improve  system 
performance.  "  — . -  -  * 


Open  Architecture 

Softool  is  committed  to  a  totally  open  architecture,  allowing  easy  access  to  all  CM 
information.  All  CCC/Harvest  control  iitformation  is  stored  within  a  relational  database.  This 
information  is  t3q)ically  accessed  fluou^  the  server  from  the  GUI  or  API  However,  a  site 
may  access  the  database  directly  for  purposes  of  report  generation  or  integration  with  other 
development  tools. 

The  acmal  data  being  controlled  by  CCC/Harvest  is  stored  within  the  CCC/Harvest  change 
repository.  The  change  repository  is  accessed  by  the  delta  engine,  which  is  part  of  the 
CCC/Harvest  server.  The  CCC/Harvest  change  repository  may  be  distributed  anywhere 
across  the  file  system  addressable  by  the  server  process.  A  site  may  wish  to  distribute  the 
change  repository  based  on  application  or  target  platform.  Data  of  any  type  from  any  client 
environment  may  be  stored  in  the  change  repository. 


Installation  Requirements 


CCC/Harvest  runs  on  a  number  of  different  platforms  and  supports  a  number  of 
commercially  available  databases.  A  mn-time  version  of  the  relational  database  is  required 
for  normal  operations  on  the  platform  on  which  the  CCC/Harvest  control  information 
database  will  be  stored.  The  CCC/Harvest  control  information  database  may  reside  on  the 
same  or  different  platforms  as  the  CCC/Harvest  server  process. 


Summary 


The  design  of  CCC/Harvest  combines  flexibility  with  power.  CCC/Harvest  allows  you  to 
take  full  advantage  of  the  strengths  of  the  client/server  environment  because  it  supports  a 
clear  separation  of  data,  its  logical  structure,  and  its  physical  location  in  the  enterprise. 
CCC/Harvest  integrates  the  critical  areas  of  change  management,  problem  management,  and 
process  management  into  one  seamless  control  environment. 

But  CCC/Harvest  does  not  just  provide  powerful,  integrated  functionality.  All  of  this  power 
is  wrapped  in  a  state-of-the-art  graphical  user  interface  that  simplifies  the  execution  of 
functions  and  minimizes  user  training.  The  easy  access  to  information  increases  management 
visibility  and  provides  supports  for  other  functions  like  auditing. 
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With  CCC/Harvest,  an  organization  defines  its  environments,  without  progiamming,  to  tailor 
the  system  to  its  needs.  Default  environments  are  also  provided  that  may  be  used  as  is  or 
further  modified.  Companies  may  have  one  standard  environment  for  all  software 
development  and  maintenance,  or  many  different  environments,  each  tuned  to  the  dynamics 
of  the  particular  software  development  and  maintenance  effort 

CCC/Harvest  can  provide  an  organization  with  all  of  the  following  benefits: 

•  Adapts  easily  to  site-specific  procedures  and  processes 

•  Implements  quickly,  providing  a  rapid  return  on  investment 

•  Facilitates  integration  with  other  development  and  maintenance  tools  through  an  open 
architecture  and  application  programming  interface 

•  Provides  a  consistent  interface  across  all  development  and  maintenance  platforms  in  the 
environment 

•  Supports  all  groups  involved  in  the  development  and  maintenance  life  cycle 

•  Protects  current  investment  CCC/Harvest  adapts  to  homegrown  and  paper  procedures 
and  provides  upward  compadbility  for  sites  currently  using  CCC  products. 

CCC/Harvest,  with  its  flexibility  and  power,  represents  the  next  generation  of  change  and 
configuration  management  products.  Its  design  is  the  culmination  of  over  17  years  of  proven 
change  and  configuration  management  experience  gained  at  hundreds  of  installations  by 
Softool  staff  worldwide.  You  too  can  begin  to  reap  the  benefits  of  this  experience  with 
CCC/Harvest. 
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APPENDIX  L 


COMPUTER  SYSTEM  DATA  SHEETS 


^AT&T 

•  AIKTSurity™ 

Data  De\ice  1910  For  Secure, 
(’lassified  Applications 


Tlic  A'fc^^T  ,S//n'n’l9ata  Device  1910  provides  a  simple  and 
cost-effectiv'e  v\xiy  to  protect  classified  government  data 
transmissions.  Developed  under  the  L’.S.  Government's 
STl/-in  program,  it's  approved  for  use  by  federal  depait- 
menLs,  agencies  and  government  conmictors. 

The  Siifity  Data  Device  is  part  of  an  ATtiT  family  of 
products  for  secure  voice  and  data  applications.  Fach 
is  full-featured  —  and  compact  enough  to  be  carried  in 
your  briefcase  w  hen  you  travel. 

Doctiine  governing  the.se  and  other  STTAIII  products 
is  established  and  controlled  by  the  D.S.  Gov  ernment. 

Protection  for  facsimiles,  electronic  mail  and 
computer  communications. 

Whether  yoifie  accessing  a  computer  databa.se. 
sending  li  fax  or  using  electronic  mail,  v'ou  can  be  sure 
v'our  infomiatkm  is  protected  —  legardless  of  the 
classification  level. 


Cost-saving  transmission  over  public  and 
government  switched  networks. 


The  AT8iT  Siifity  Data  Device  can  be  used  to  transmit 
information  over  any  public  or  government  .switched 
netwx:)rk  at  speeds  of  up  to  14.4  kbps.  You  won  t  need 
an  expensive,  dedicated  transmission  path  to  ensure 
data  securiw. 


Government-approved  for  unattended  operation. 

The  KY8cT  Siuitv  Data  Device  is  approved  by  the 
government  for  unattended  secure  ckiui  transmission. ,\s 
Li  result,  facsimiles  and  other  data  communicLitions  can 
be  sent  to  you  even  while  you're  away  from  your  office. 

Comprehensive  service  and  support. 

XY&Ts  toll-free  hotline  provides  a  single  point  of 
contact  for  comprehensive  service  and  support.  With  a 
phone  call,  you  can  resolve  a  question,  place  an  order. 
troul:)leshoot  problems  and  more. 

Repairs  are  hassle-free.  If  your  terminal  fails,  we  ll 
send  you  a  replacement  overnight.  We  re  the  only 
company  in  the  industry  to  do  so.  And  we  stand  behind 
the  Siifity  Data  Device  with  a  full.  twx)-year  wxirranw 
with  a  one-year  extension  or  five-year  conversion. 


Feature-rich. 

AT&T  designed  the  Surit}’  Data  Device  with  features 
and  functions  that  lead  the  market  and  support  our 
customers’  special  needs. 

•  Access  Control.  The  AT&T  Siifity  Data  Device  is 
equipped  with  a  unique  Securitv'  Access  Control 
System  (SACS)  that  brings  unmatched  flexil^ility  to 
your  data  applications. 

SACS  allows  you  to  establish  a  secure,  closed 
netwx)rk  and  to  control  access  to  facsimile  machines 
or  data  stored  on  a  PC  or  host  computer.  You  simply 
program  a  list  of  authorized  user  IDs  into  your  AT&T 
Siirity  Data  Device.  SACS  automatically  screens 
incoming  calls,  comparing  the  ID  of  the  caller  to  those 
on  your  list.  Unauthorized  attempts  are  disconnected 
before  the  caller  has  access  to  v^our  files. 


.Access  can  also  be  controlled  by  .setting  the  device 
for  minimum  or  maximum  security’  levels.  Only  calls 
vvitii  tlie  appropnate  ckLssilication  lev’el  will  Ix"  accepted. 

.As  an  additional  security’  feaaire.  the  AT&T  Siinty 
Data  Device  prov’ides  the  information  you  need  to 
maintain  an  audit  trail  of  all  attempts  to  acce.ss  your 
network  —  w  hether  succe.ssful  or  ncu. 

•  Remote  operation.  You  can  control  the  .AT&T 
A>/nVv  Data  Device  remotely  from  anv  fax.  P(]  or 
computer  that  is  connected  to  its  25-pin  RS-232  data 
port.  Remote  commands  are  Ixised  on  the  Hayes 
SmartAIodem  2a00'^'  command  set. 

•  Compatibility.  A  full  range  of  data  speeds  —  I  rom 
2.'i  kbps  half  duplex  to  9.6  kbps  full  duplex  — 
makes  the  AT&T  device  compatible  w  ith  the  secure 
data  operation  of  any  STU-III  v’oice/data  terminal. 
Data  compression  capability’  in  the  Model  1910  pro¬ 
vides  effective  data  transmission  at  speeds  of  up  to 
38.4  kbps  (when  used  w’ith  a  compatible  unit  that 
transmits  and  receiv’es^at  38.4  kbps). 

•  Easy  instollation/operation.  The  AT&T  Sinity 
Data  Device  is  easy  to  install.  You  plug  in  the  power 
cord  and  a  telephone  jack  and  connect  the  unit  to 
your  PC,  facsimile  machine  or  computer. 

Mer  completing  an  automated  key  management 
procedure,  the  unit  is  ready  to  gc3  secure. 

Operation  is  simple.  No  special  training  or 
cuml^ersome  routines  are  required. 

For  more  information. 

The  AT&T  Siifity  Data  Device  can  provide  you  with 

significant  sav’ings  over  traditional  data  securitv  solutions. 

To  find  out  more,  call:  800  243-7883,  or  910  279-3411 

(outside  the  U.S.  and  Canada). 

‘National  and  local  security  policies  apply. 


^AT&T 

#  ACSTSurity™ 
Data  Device  1910 


SPECIFICATIONS 

Information  protected 

•  U.S.  Government  top  secret,  secret,  confidential  and 
unclassified 

User  community 

•  I  fS.  Federal  Government  •  I  '.S.  Gov  eminent  conuactors 

Security  features 

•  Security  Access  Ca)ntrol  •  FulK'  automated  STI  '-III 

System  ( SACS )  fill  procedures 

•  Maximum  and  minimum  •  Display  window  for 

security-level  settin.t^  autlienticaiion  identilication 

•  Auio-answer.  auto-secure  •  Information  to  create  a 

•  I'empest  call  audit  trail 

•  (irv  pto-lL'nition  Key  KilK) 

•  Active  and  passive 
terminal  zeroization 

Key  management 

•  Master  CIK  •  Dual  key  sets 

•  Travelin^  CIK  •  Hiulu  ClKs  per  kev  s( 


Secure  data  operational  modes 

•  H.4  kbps  full-duplex  •  2.* 

sync/async  sy 

•  9.6  kbps  full-duplex  •  2.- 

sync/async 

•  4.8  kbps  full-duplex 
sync/  async 

Modem  characteristics 

•  Data  compression  CCITT  •  2. 

\’.42  bis  se 

•  N'ear; far  echo  cancellation  lU 

•  Frecjuency  ot  fset  •  2. 

compensation  >c 

•  1 4.4  kbps:  CiCITT\'.32  bis  •  in 

secure:  sync  async:  full  •  < ) 

duplex  with  optional  to 

trellis  coding  •  Ai 

•  9.6  kbp.s:  CCITT  V.32  fn 

secure:  sync/ async:  full  to 

duplex  with  •  Rt 

optional  trellis  coding  H 

•  4.8  kbps:  CCITT  \’.32 
secure:  sync.' async;  full 
duplex 

Interfaces 

•  External  power  supply  •  RJ 

•  EIA  RS-232  data  pon  witli  cv 

a  25-pin  D-connector  te 

•  RJ  11..  RJ  13  telephone  jack  •  A 

lo  connect  to  public  k< 

switched  network.  FAI3X 

or  kev  svsiems 


Dual  key  sets 
Eight  Clks  per  key  .set 


1.4  kbps  full-duplex 


svnc/asvnc 


:.4  kbps  half-duplex  sv'nc 


'  2.4  kbps:  (XITT  \'.2()  bis 
secure:  sync  a.sync:  full 
(.luplex 

•  2.4  kbps:  CCITT  \'.26  bis 
secure:  .sync:  half  duplex 

►  input  level:  0  to  -43  dl3m 

•  (iutpLiL  lev  el:  adjustable..  0 
to  -15  dBm 

►  Automatic  rate  fallback: 
from  l4.4.  9.6  and  4.8  kbps 
to  2.4  kbps 

•  Remote  control  using 
Haves  AT  commands 


'  RJ13  auxiliarv'  .set  jack  to 
c(.:)nneci:  standard 
teleplione  ( optional ) 

*  Al  leads  (for  use  with 
key  telephone  systems ) 


Physical  characteristics 

•  8"w  X  2.5"h  X  9.5"d  ( 20.3  •  Desktop  or  rack-mountable 

cm  X  (x3  cm  x  2  i.l  cm; 

•  "  lbs.  (3. 1  kg; 

Environmental 

•  (Operating  temperature:  •  Relative  [tumidity  (storage 

i( )-  to  1  ( )0-F  ( 4 . 5-  to  38--C )  U )  95'^  1 1  m  )nc( tndensin; 

•  Storage  temperature:  -40- 
to  150-F  (-4(.)-  to  ()(y-C) 

Power 

•  External  power  supply  •  lnf:)ut  frecjuency  }“'-63  H 

^eiectaide  90-134\’  ac.  •  Input  p<  Aver  ciissifxition 

186-253\'ac  l(t  watts 

Equipment  interoperability  (data  mode) 

•Sl'r-IIl  LCr.  A  and  Cellular  ' 

Equipment  compatibility^ 

•  Data  devices  with  RS-232  •  Digital  facsimile 

output 

Compliance  with  standards 

•  FC('  Fan  15.  Subpan  I .  •  TSG5  -  on-hook  acou.stic 

Class  B  .secLiritv 

•  FCC  Fan  (t8  •  .VlIL-STl)- 14'2  .Acoustical 

•  ['L  I  t59  \oLse.  Curve  .\C-35 

•  I  iLTT  A'  CSA  (power  •  E.MC T.MI  MIL-STD-46IC 

supply)  •  ESI)  20  kV 

•  Tempest  N.ACSI.M  5100A  •  21  ho.st-nalion  approval.^ 

Warranty^ 

•  24  months  standard  •  Fost-wan'antv’  .seiv  ice 

•  12-month  extension  or  available 

5-year  conversion 

Options 

•  (ianying  case 

Note: 

''(Kvilicaix  >n.s  Mii-tjfa  lo  dlan^L•  wiiIkhu  ikhkc.  I  Acmmctu  ivmii.moti.s 

apply  tor  purdui.se. 

Trademarks: 

llavc.s  IS  a  rciii-SKTcd  trademark  ot  I  (a ves  VlieroeointHiier  i^roduels.  Ine. 
Mnarl.\lodein  J  lOtl  is  a  iradenuirk  of  Uave.s  Mieroeoiujiuler  Products.  Ine 

ATScT 

Surity  Communications  Froducts 
Customer  Serv’ice  Center 
F.O.  Box  20046 
Greensboro.  N'C  2~420  l.'S.A 
Fhone:  800  243-“'883 

910  279-3-tll  (outside  U.S.  and  Canada) 


Relative  [tumidity  (storage): 
to  95'Si  nt  )ncondensinu 


•  lnf:)uL  frecjuency  Hz 

•  Input  p<  AVer  dissifxition 
l(t  watts 

(data  mode) 


Digital  facsimile 


>  TvSG5  -  on-liook  acou.stic 
secLiritv 

•  .VlIL-STb-Fr2.Acou.stical 
\oLse.  Curve  .\C-35 

>  E.MC U.MI  MIL-STD-46IC 

•  ESI)  20  kV 

>  21  ho.st-nalion  approvals 

»  Fost-wananiv’  .seiv  ice 
available 


Prime'.  1  ' 'li  i\eevdec.i  Pap<.'r 


()  9t 


AT&T 


#  AIKTSurityr^' 

\bice/  Data  Terminal  1100 
For  Secure. 

('lassi  lied  Applications 


Idle  A'TScT  Siifitv  Voice/ Data  Terminal  prox'icles  secure, 
cla.ssified  \T>ice  and  data  communications  in  one 
integrated  package. 

It  \\'orks  l^oth  as  a  Full-featured  telephone  for  \'oice 
calls  and  as  a  smart  modem  for  data  applications.  Fait 
of  an  A'FckT  family  of  Siifitv  products,  the  \^)ice/Data 
Terminal  is  compact  and  light  enough  to  cariy^  with 
you  when  you  tra\  el. 

IXneloped  under  the  U.S.  Gox  ernmeni  s  S'llMII 
{'jrogram.  the  terminal  is  appro\'ed  for  use  hy  federal 
eiepaitments.  agencies  and  government  contractoi's. 

lX)ctrine  governing  these  and  other  AIT '-III  products 
is  esuU')lisheci  and  controlled  by  the  government. 


One  product  for  two  jobs. 

If  \^ou  need  both  .secure  voice  and  secure  data,  the 
ARkT  Siifily  \'oice/  Data  Terminal  can  save  you  monev. 
You  won't  need  to  clutter  your  desk  with  a  secure 
phone  cDici  a  secure  modem. 

Cost-saving  transmission  over  public  or  government 
switched  network. 

AT<!^Ts  terminal  is  designed  to  secure  both  voice  and 
data  transmissions  ov  er  public  or  government  switched 
networks,  Abu  won  t  need  an  expensive,  dedicated 
transmission  path  to  ensure  securin’.  Data  can  he 
transmitted  at  speeds  of  2.4.  -t.8  and  9.6  kbps  —  voice 
at  2.4  and  4.(S  kbps. 


Protection  for  facsimiles,  electronic  mail  and 
computer  communications. 

W’hether  you're  accessing  a  computer  database,  sending 
a  fax  or  using  electronic  mail,  you  can  be  sui’e  v'our 
information  is  protected  —  regardless  of  the 
classification  level. 


Government-approved  for  unattended  operation. 

The  AT^^T  5///7'(r  \bice/Data  Tenninal  is  approv'ed  by  die 
gov’emment  for  unattended  .secure  ckita  nxiasmission. "  As 
a  result,  facsimiles  and  other  data  communications  cxin 
lx?  sent  to  v'ou  ev’en  wiiile  you're  away  from  your  office. 


Superior  voice  quality. 

In  the  past,  making  a  secure  telephone  call  has  meant 
compromising  v’oice  qualitvc  That's  not  the  case  with 
the  ATtxT  5///7(r  Voice/ Data  Terminal.  WeVe  made 


cenain  that  the  v’oice  quality  of  your  .secure  calls  will 
be  comparable  to  that  of  your  clear  ( non-secure )  calls. 

Comprehensive  service  and  support. 

AT&T's  toll-free  hotline  provides  a  single  point  of  contact 
for  comprehensive  sendee  and  suppoit.  With  a  phone 
call,  you  can  resolve  a  question,  place  an  order, 
troubleshoot  problems  and  more. 

Repairs  are  ha.ssle-free.  If  your  terminal  fails,  we'll 
send  you  a  replacement ov'ernight.  Were  the  o}\iy 
company  in  the  industiy  to  do  so.  And  w’e  stand 
behind  the  Voice/  Data  Terminal  with  a  full, 
tw’o-year  vvaiTantv’  and  optional  one-vear  extension  or 
fiv’e-v’ear  conv'ersion. 


Feature-rich. 

AT&T  designed  the  Siinly  Voice;  Data  Terminal  with 
feaaires  and  functions  that  lead  the  market  and  suppoit 
our  cu.stomers'  special  needs. 

•  Speakerphone.  A  built-in  speakerphone  gives 
you  hands-free  operation  for  both  .secure  and  regular 
phone  calls. 

•  Access  control.  The  .AT&T  lemiinal  Lsecjuippcxl  vvitli  a 
unique  .Secuntv'  .Accevss  Cd  >itU’ol  System  (SACS)  tltat  biings 
unmatched  Ilexibility  to  applications  recjuinng  .secuiitv’. 

SACS  allows  you  to  e.stablish  a  .secure,  cl o.sed 
network  lor  both  v'oice  and  data  communications. 
You  can  control  access  for  .secure  phone  calls  or 
iacsimile  transmi.ssions  and  protect  data  stored  on  a 
PC  or  ho.st  computer. 

To  do  .so.  you  simply  program  a  list  of  authorized 
u.ser  IDs  into  v’our  xAT&f  temiinal.  SACS  automaticallv' 
.screens  incoming  calls,  comparing  the  ID  of  tlie 
caller  to  tho.se  on  your  li.st.  l/nauthoriz.ed  attempts 
are  disconnected  before  the  caller  has  acce.ss. 

You  can  also  control  acce.ss  by  .setting  your  tenninal 
for  minimum  or  maximum  .securiy  levds.  Only  calls 
with  tlie  appropriate  cla.ssiTication  level  will  be  accx?pted. 

As  an  additional  security  feature,  the  AT&T  Siniiy 
\bice/Data  Terminal  provides  the  inlbrmation  you 
need  to  maintain  an  audit  trail  of  all  attempts  to 
access  ycuir  netw’ork  —  whether  succe.ssful  or  not, 

•  Easy  installation/operation.  Regardless  of  your 
application,  the  AT&T  Sinity  Voice/  l3ata  lenninal  is 
easy  to  .set  up  and  to  operate.  To  install,  you  plug  in 
the  power  cord  and  a  telephone  jack  and  connect 
the  unit  to  your  PC,  facsimile  machine  or  computer. 

After  completing  an  automated  kev'  management 
procedure,  the  unit  is  ready  to  go  .secure. 

Operation  is  simple,  and  no  special  training  is 
required. 

•  Remote  operation.  For  data  applications,  you  can 
control  your  AT&T  Siuiiy  Voice/ Data  Terminal 
remotely  from  any  fax.  PC  or  computer  connected  to 
its  RS-232  data  poit.  Remote  commands  are  based  on 
the  Hayes  SmaitModem  2  tOO'^'  command  set. 

•  Compatibility.  The  AT&T  6bn(v  Voice/ Data  Tenninal 
is  compatible  with  STU-III  voice/ data  terminals 
ciurently  fielded,  including  the  1000  and  2000  Series 
ot  AT&T  5/ //7/t’ Communications  Products. 

For  more  information. 

The  AT&T  Siuity  Voice/ Data  Terminal  provides  a  cost- 
effective  approach  to  your  .security  needs.  To  find  out 
more,  call;  800  243-7883,  or  910  279-341 1  (outside  the 
IJ.S.  and  Canada). 

’N.uiotial  and  local  set  urity  polit  ics  apply. 


^  /NISSrSurity*'' 
\bice/Data  Terriiinal  1100 


Specifications 

hiformation  protected 

•  I  '.S.  Cj()\  cmment  top  secret, 
unclassified 

User  community 

•  I  fS.  Ix'derai  Gox  emnient 

Security  features 

•  Securiiv  Access  ("ontroi 
Svsteni  iSACS) 

•  Maxinuini  and  minimum 
securiu'  le\  el  settin” 

•  Auio-answer.  auto-secure 

•  rempesl 

•  (;r\  pU)-lynition  Ke\-  (C'lK) 

•  Active  and  passive 
terminal  /.eroization 


secret,  confidential  and 


•  I  f  S.  G(  )vemnient  c(  )ntraa(  )i's 

•  Fully  automated  S^R’-IIl 
fill  procedures 

•  Display  window' 
for  authentication 
identification 

•  infonnation  to  create  a 
call  audit  trail 


Key  management 

•  Master  C\K 

•  'I  ra\eling  CIK 
Voice  modes 

•  edear  \'oice 

•  Secure  \'oice 

a.8  kbps  full-duplex  CHIP 
.1  t.8  kbps  hill-duplex  RDU^C 
Telephone  features 

•  Speakerphone- clear 
and  secure 

•  (dn-hook  dialing 

\\  ith  speakerphone 

•  Speaketphone  volume 
c(  )ntr(  )1 

•  Pulse  or  tone  dialing 

•  Last  number  redial 

•  Repenoiy  dialing 

(32  numbers  on  single 
line/ 20  numbers  on 
multiline) 

•  l^rogrammable  pause 

•  Dial  tone  detect 

•  Secure  dialing 

•  Switch  h(x)k  flash 

•  Automatic  disconnect 


'  Four  key  sets 
'  Eight  Clks  per  key  set 


:  2.4  kbps  full-duplex  LlKdOe 
4  24  kbps  hall-duplex  LPClOe 

•  Ringer  \'olume  control 

'  Ringer  cutoff 

•  Handset  \'oIume  control 

•  iMicrophone  niute 

( disconnects  microphone 
on  both  handset  and 
speakerphone) 

» 2-line  by  id-character 
Liquid  Cry'Sttil  Display  ( L(dd) 

►  PABX  compatible 

►  Auto  von  precedence 
signaling  dear  and  secure 

►  Autovon  preempt 
detection  clear  and  secure 

►  Multiline  Model  1150  for 
use  with  lA  key  systems 
(optional) 


Secure  data  operational  modes 

•  9.6  kbps  full-duplex  •2.4  kbps  full-duplex 


sync/as\'nc 

•  ^.8  kbps  hill-duplex 
sync/async 

Modem  characteristics 

•  Near/ far  echo  cancellation 

•  Frequence  offset 
compensation 

•  9.6  kbps:  Cenr  V.32  seaiie: 
s\Tic/as\’nc:  hill  duplex  with 
optional  trellis  coding 

•  4.8  kbps:  CCFTT  V.32  stxiue: 
svnc/asvnc;  hill  duplex 

•  2' 4  kbps:  CCITTV.26  bis 
seciire;  s\tic  as\nc:  hill  duplex 


sync/async 

» 2.4  kbps  half-duplex 
sync 

►2.4  kbps:  CCITTV.26  bis 
secure:  sync;  half  duplex 

►  Input  level:  0  to  -43  dBm 

►  Output  level:  adjustable.  0 
to  -15  dBm 

►  Automatic  rate  fallback: 
from  9.6  and  4.8  kbps  to 
2.4  kbps 


Interfaces 

•  External  power  supply.  •  Auto\'on  2-wire 

lEC  320.  CEE-22  connector  •  A/  A I  leads  (for  use  with 

•  EIA  RS-232  data  poiT  with  key  telephone  svstems) 
a  25-pin  D-connector 

•  Rj  1 1/  KJ13  telephcme  jack 
to  connect  to  public 
switched  network.  PABX 
( )r  key  system 

Physical  characteristics 

•  M“w  X  3.25”h  X  IT'd  (22.9  •  10  lbs.  (  1.5  kg) 

cm  X  8.2  cm  x  2^.9  cm) 

Environmental 

•  ( )perafing  temperature:  •  RelatKe  luimiditv 

lO  to  lOO-F  (4.5  to  38-C)  (.storage):  to  9S‘’o 

•  Su  )rage  temperaaire:  m )nc(  )nt.lensing 

-40  to  150-F  (-40  to  (')(y-C) 

Power 

•  E.xtemal  power  supply  •  Input  power  dissipation 

auto  ranging,  90-253V  ac  16  watts 

•  Input  frequency  47-63  Hz 
Equipment  interoperability 

•  STl  :-III  LCT.  A  and  Cellular 
Equipment  compatibility 

•  Data  dewices  with  •  Digital  facsimile 

RS-232  output 

Compliance  with  standards 

•  FCC  Part  15.  Subpan  I.  •  :VIIL-S'n>  1 4"2  Acoustical 

Class  B  Noise.  Cuiv'e  NC-35 

•  FCC  Pan  (^8  •  EMC  EMI  .MIL-S113-46 IC 

•  DL  1459  •  ESD  20  k\’ 

•  (  T  TLA' (2SA(powei' supply)  •  HF’MP-NSA  ””-2“' 

•  NSTISS.VM  Tempest  1-91  •  21  host-nation  approvals 

•  I'SG  5  -  on -hook 
acoLustic  securin' 

Warranty 

•  24  months  standard  •  Post- warranty  .seivice 

•  12-month  extension  or  available 

5-year  conversion 

Options 

•  Carrying  case  •  Push-lo-talk  handset 

•  .Multiline  ( 5  lines  and  •  FWA- 1  h  )u r-wire/  twe  )-l  i ne 

hold;  to  be  used  with  adapter 

lA  key  .systems) 

Notes 

Spcciticaiion.s  .subject  to  change  without  notice.  I  '.S.  ('lovernment 
regulations  apply  tor  purcha.se. 

Trademarks: 

(iLives  is  a  registered  trademark  ol  Hayes  .Microcomputer  l4oducts.  Inc. 
SmartModem  i-tOO  is  a  trademark  of  liayes  .Microcomputer  Ihdducts.  Inc. 

AT&T 

Surity  Communications  Products 
Customer  Service  Center 
P.O.  Box  20046 
Greensboro,  NC  27420  USA 
Phone:  800  243*7883 

910  279-3411  (outside  U.S.  and  Canada) 
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Network  Interfacer  Unit 


The  most  flexible,  portable  DiS  toolkit  available 


Proven  Technology 

'Developed  by  Motorola  and  NAWC- 
TSD  and  erilia need  by,  DiSTI,  the 
DIS  Daemon  rs  being  used  ,  on  a 
number  dt-‘  programs.  >  including. 
JS  TAfiS.'  BFT  I  .-  and  NASNEl?.  One 
of  the  first  applications  pf  its  kind  tlie 
DIS  Daemon  has  been  in  use  since 
1992. 

Flexible  and  Scatable  Architecture 
'Multiple  applications,  can  attach 
simultaneously  to  the  DIS  Daemon  to 
share  one  DIS  network  interface,  a 
featLiie  which  costs  extra  with  other 
DIS  interlaces,  i  the  DIS  Daemon  can 
run  under  UNIX  or  can  be  embedded 
bn  a  VME;  Single  Fioard  Computer 
(SBC),  tc  free  ttie  host  system  from 
DIS  processing  If  more-  ppvver  is 
needed;  then  the  DIS  Daemon  can  be 
distributed  across  up  to  three 
processors. 


1 


‘'1& 


Cross  Platforpi  Portability 

Applications  which  use  ttie  DIS 
Daemon  are  readily  portable  to  most 
UNIX  systems  anti  leal-time  systems 
withput  the  treed  for  special  compileis 
or  :  proprietary  libraries'  I  he  DIS 
Daemon  itself  can  easily  be  ported  to 
new  environnienls,  since  complete 
commented  source  code  is  available 
No  other  product  otters  this  capability. 

Support 

DiSTl..  the  leadei  in  DIS  education 
has  the  expert  stalf  to  answer  youi 
questions  about  DIS  and  real  time 
systems  Fdus.  the  DiSTI  staff  is  woli 
veised  m  the  issues  of  DIS 
compliance  testing 

(M  MOTGfiOLA 
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DiSTI 
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Network  Interfaces  Unit 


Key  Features 

Certified  DIS  Interface  supports  DIS  versions 
from  2.0.3  to  the  latest  draft  standard 

Scalable  performance-split  the  DIS  load  over 
multiple  CPUs 

Runs  on  over  a  dozen  different  operating  systems 

Source  code  at  no  extra  cost  for  government 
purpose  customers 

One  Daemon  supports  multiple  DIS  applications 
simultaneously  at  no  extra  cost 

Simple  but  powerful  configuration  files  to 
configure  almost  any  option 

Complete  Set  of  Entity  Management  Functions 

•  Built-In  support  for  Simulation  Management 

•  Automatically  issues  Entity  Stale  PDUs 

^  •  Implements  atl  OIS  Dead  Reckoning  Algorithms 
■  •  Automatic  entity  collision  detection  and  PDU 
generation 

•  Entity  position  smoothing 

Automatic  Conversion  to  Geodetic.  UTM, 
Topocentnc,  and  Geocentric  coordinates 

Syte  swaps  PDUs  on  little-endian  computers 

Filter  by  location,  PDU  type,  exercise,  or  any 
oart  of  the  entity  type  field 

Intuitive  X  Windows  User  Interface 

Logger  and  Playback  software  included 


For  more  information  visit  our  Web 


PDU  TRANSMIT 


COORDINATE 


CONVERSION 


Available  Now  for 

Silicon  Graphics  (IRIX  4.05,5.2,  5.3  &  6.2) 

SunOS 

Solaris 

HPUX 

Motorola  UNIX  SVR3,  SVR4 
Motorola  VME  Exec  3.0 
Linux 

DEC  0SF./1 
AIX  4.1.3 
Harris  Nighthawk 

Available  Soon 

Motorola  VME  Exec  4.0 
VxWorks 

Site  at  http://www.simulation.com  or  call  407-339-8288 


DISTI 


unOS  is  a  registered  trademark  of  Sun  Microsystems  Computer  Corporation, 
olarii  is  a  registered  tradennark  of  Sun  Microsystems  Computer  Corporation. 


AIX  it  a  registered  trademark  of  International  Business  Machinei  Corporatior. 

UNIX  is  a  registered  trademark  of  UNIX  Systems  Laboratories  a  wbolty 
owned  subsidiary  of  Novell  Inc. 


Motorola,  the  Motorola  logo,  and  VMEexec  are  registered  trademarks  of 
Motorola,  Inc. 

Motif  is  a  trademark  of  the  Open  Software  Foundation.  Inc. 

X  \Mndow  System,  X1 1 .  and  X  are  trademarks  of  Massachusetts 
irwtitule  of  Technology 
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SPARCstation  4: 

The  Low-Cost  System  for  High-Performance 


Network  Computing. 


Table  of  Contents 

•  It’s  expandable  enough  to  keep  pace  with  vour  business. 

•  The  Innovative,  energy-efficient  design  saves  more  than  just  money. 

•  SPARCstation  4  Specifications. 


In  today’s  hurry-up  work  world,  you  can’t  wait  for  your  computers  to  catch  up.  Whatever  job  your  group 
does  —  computer-aided  software  engineering,  management  and  support,  telemarketing,  customer  service  — 
your  desktop  systems  have  to  be  responsive  enough  to  keep  your  people  productive,  yet  inexpensive,  so 
everyone  can  have  one. 


That’s  the  essence  of  the  SPARCstation  4  system.  Driven  by  a  powerful  1 10-MHz  microSPARC-II 
processor,  the  SPARCstation  4  delivers  all  the. balanced  application  performance  you  could  want  in  an 
entry-level  system.  Accelerated  screen  performance  means  fills,  text,  and  scrolling  are  remarkably  fast. 
Powerful,  flexible  video  memory  augments  screen  speed  even  more,  in  resolutions  as  high  as  1280  by  1024 
—  with  no  degradation.  And  with  the  pixel  accelerator’s  reduced  circuitry,  the  SPARCstation  4  delivers 
power  and  functionality  to  the  desktop  at  a  very  affordable  price. 


Plus,  you  benefit  from  the  high-performance,  feature-rich  Solaris®  operating  environment,  the  most 
powerful,  popular,  and  easy-to-use  32-bit  operating  environment  in  the  industry.  Link  that  with  the 
SPARCstation  4's  multitasking  ability,  and  you  can  run  all  your  UNIX,  Macintosh,  MS-Windows,  and 
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MS-DOS  applications  from  this  single  desktop  system  --  simultaneously. 

•  Advanced  networking  lets  you  share  files  and  applications  with  your  coworkers,  too,  regardless  of  where 
they’re  working.  In  addition,  your  entire  network  has  access  to  the  workgroup  and  enterprise  information 
they  need  to  make  well-informed  business  decisions. 

It’s  expandable  enough  to  keep  pace  with  your  business. 

Sometimes  you  don’t  need  just  more  memory;  you  need  control  over  what  kind,  how  much,  and  what  it 
costs.  That’s  the  beauty  of  the  SPARCstation  4:  you  gauge  and  pay  for  only  the  memory  you  require  to 
make  your  graphics  applications  run  at  their  peak.  Floppy-disk  and  CD-ROM  drives  and  audio  and  video 
memory  expansion  are  options  if  you  need  them.  Up  to  160  MB  of  memory  expansion  is  available  using  8- 
or  32-MB  SIMMs.  And  the  10-MB/sec  SCSI-II  bus  puts  you  in  touch  with  a  possible  55  GB  of  external 
mass  storage  and  lets  you  access  that  data  with  incredible  speed. 


The  innovative,  energy-efficient  design  saves  more  than  just  money. 


In  today’s  economy,  businesses  are  always  on  the  lookout  for  innovative  ways  to  reduce  costs.  And 
increasingly,  those  businesses  are  realizing  cost  savings  by  cutting  energy  consumption.  That’s  why  the 
Energy-Star-compliant  SPARCstation  4  has  so  many  features  that  help  cut  utility  costs  built  right  in. 


For  example,  the  system  automatically  enters  a  power-save  state  when  it’s  not  in  use.  And  its  50-watt 
power  supply  -  smaller  than  on  most  PCs  -  cuts  power  consumption  and  reduces  the  demand  on 
air-conditioning  systems,  while  the  smaller  cooling  fan  lets  the  system  run  quieter,  too.  Your  business  wins 
and  so  does  the  environment. 


Fast,  well-balanced  performance,  built-in  advanced  networking,  flexible  expansion,  and  stingy  with 
energy,  the  SPARCstation  4  is  a  true  example  of  what’s  best  about  the  open  network  computing  promise. 


SPARCstation  4  Specifications 


Processor 


Architecture:  SPARC  Version  8,  1 10-MHz  microSPARC-II 
Memory  management;  SPARC  reference  MMU  with  256  contexts 
Cache:  8-KB  data  and  16-KB  instruction  on  chip 

Main  Memory  (Parity) 

8-  and  32-MB  SIMM  expansion 
40  MB  maximum  (with  8-MB  SIMMs) 

160  MB  maximum  (with  32-MB  SIMMs) 

Standard  Interfaces 


Ethernet:  10-Mb/sec  twisted-pair  standard  (10-BaseT);  AUI  standard 

•  SCSI:  10-MB/sec  SCSI-2  (synchronous) 

Serial:  One  RS-232C/RS-423  serial  port 

Second  asynchronous  serial  port  available  (adapter  cable  required) 
Parallel:  Centronics-compatible  parallel  port 
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Audio:  Optional  16-bit  audio;  48  kHz;  internal  speaker  and  external  microphone  (audio  module  required) 
SBus;  One  expansion  slot;  32-bit  data  bus  width 


Mass  Storage 


Internal  floppy  disk;  Optional  3.5-in.  MS-DOS/EBM®  compatible  (720  KB,  1.2  MB,  1.44  MB  formatted) 
Internal  CD;  Optional  644-MB  SunCD  2Plus;  double  speed,  PhotoCD  compatible 
Internal  disk;  One  3.5-in.  x  1-in.  pluggable  disk  (1.05  GB  formatted) 

External  desktop  storage;  Disk;  1.05  GB  3.5-in.;  2.1  GB  3.5-in.;  4.2  GB  3.5-in.;  55  GB  max.  (using 
4.2-GB  external  disks);  644-MB  CD-ROM;  Tape;  QIC- 150;  5-GB  4mm,  14-GB  8mm  DAT;  20-GB  4mm 
DAT  auto  loader 


Graphics 

8-bit  pixel-accelerated 

1024  X  768, 1 152  X  900  res.  standard 

1280  X  1024  res.  optional  (video  memory  expansion  SIMM  required) 


Monitor  Options 


17-in.  entry  color:  1024  x  768  resolution,  77-Hz  refresh  rate,  100  dots  per  inch 

1152  X  900  resolution,  66-Hz  refresh  rate,  100  dots  per  inch 

1152  X  900  resolution,  76-  or  66-Hz  refresh  rate,  100  dots  per  inc 
1280  X  1024  resolution,  76-  or  66-Hz  refresh  rate,  110  dots  per  in 

1152  X  900  resolution,  76-  or  66-Hz  refresh  rate,  84  dots  per  inch 
1280  X  1024  resolution,  76-  or  66-Hz  refresh  rate,  93  dots  per  inc 


Input  Devices 


17-in.  color: 


20-in.  color: 


Keyboard;  Sun  Type  5;  AT  101  or  UNIX  layout  available;  more  than  18  international  keyboards  available 
Mouse;  Optical,  3-button 
Microphone;  SunMicrophone  II 
Color  camera;  Optional  SunVideo 

Software 


Operating  system;  Solaris  operating  environment 
Languages;  C,  C++,  Pascal,  FORTRAN 
Networking;  ONC,  NFS,  TCP/IP,  SunNet  OSI,  MHS 
Windowing  system;  OpenWindows  Version  3 
Graphics;  SunPHIGS,  XGL,  XIL,  SunGKS,  Xlib,  PostScript 

Environment 


AC  power;  100-240  VAC,  50-60  Hz,  125  VA  (74  W  max) 

•  Operating;  0°  C  to  40°  C  (32°  F  to  104°  F)  5%  to  95%  relative  humidity,  noncondensing 

Nonoperating;  -40°  C  to  70°  C  (-40°  F  to  158°  F)  5%  to  95%  relative  humidity,  noncondensing 
Operating  acoustic  noise;  4.5  bels  (at  28°  C) 
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Idling  acoustic  noise:  4.1  bels  (at  28°  C) 

Declared  noise  emissions  in  accordance  with  ISO 
Energy  Star-compliant  chassis,  15-in.,  17-in.,  and 


9296 

20-in.  color  monitors 


Regulations 


The  initial  state  of  the  50  watt  power  supply  after  outage  is  off.  The  system  must  be  rebooted  manually 
after  a  power  outage. 


Meets  or  exceeds  the  following  requirements: 

Safety:  UL  1950,  CSA  950,  TUV  EN  60950 

RFI/EMI:  FCC  Class  B,  DOC  Class  B,  EN  55022  Class  B,  VCCI  Class  2 
X-ray:  DHHS  21,  Subchapter  J;  PTB  German  X-ray  Decree 


Dimensions  and  Shipping  Weight 


SPARCstation  4  chassis 
Height:  7.7  cm  (3.1  in.) 
Width:  41.7  cm  (16.4  in.) 
Depth:  40.9  cm  (16.1  in.) 
Weight:  12.7  kg  (27.0  lb.) 

17-in.  color  monitor 
Height:  41.4  cm  (16.4  in.) 

•  Width:  40.6  cm  (16.0  in.) 
Depth:  45.0  cm  (17.7  in.) 
Weight:  25.9  kg  (57.0  lb.) 

17-in.  color  monitor 
Height:  43.0  cm  (14.6  in.) 
Width:  42.7  cm  (14.7  in.) 
Depth:  48.3  cm  (15.4  in.) 
Weight:  19.0  kg  (37.4  lb.) 

20-in.  color  monitor 

Height:  47.1  cm  (18.5  in.) 
Width:  47.5  cm  (18.7  in.) 
Depth:  49.5  cm  (19.5  in.) 
Weight:  36.3  kg  (80.0  lb.) 


Upgrades 


Upgrades  are  available  for  the  SPARCstation  SLC,  SPARCstation  ELC,  SPARCclassic,  SPARCstation 
IPC,  SPARCstation  1,  SPARCstation  1-f-,  SPARCstation  LX,  SPARCstation  IPX,  SPARCstation  2,  Sun-3, 
and  Sun386i  systems. 


Specifications  are  subject  to  change  without  notice. 


Questions  or  comments  regarding  this  service?  webmaster@sun, com 
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SPARCstation  5:  System  Architecture 


SPARCstation  5  System:  Fast  Application  Performance 

Technology  Overview 

Through  a  fully  balanced  hardware  design,  the  SPARCstation  5  system  delivers  the  very  fast  application 
performance  that  enterprise  desktop  users  need  today. 

New  microSPARC-II  Processor 


Features 


Benefits 


-  Choice  of  85-MHz  or  110-MHz  processor 

-  16  KB  of  instruction  cache 

-  8  KB  of  data  cache 

-  Improved  floating-point  unit 

-  New  memory  management  unit  with 
256  context  switches 

-  Access  to  up  to  256  MB  of  memory 

High-Speed  Memory  Bus 


Fast  application  performance 
at  a  low  cost 


Feature 

-  6 4 -bit  high-speed  memory  bus 


Benefit 

-  Provides  fast  data  throughput 
between  CPU/memory  and  24-bit 
graphics 


SBus 


Feature  Benefit 

-  32-bit  SBus  -  High-performance  industry-standard 

bus  for  fast  graphics  and  fast  I/O 
performance 


Fast  SCSI  II  Bus  Interface 


Feature 

-  10-MB/sec.  SCSI  II 


Benefit 

Fast  access  and  retrieval  of  mass 
storage 


^1^  SPARCstation  5  S24  24-Bit  Color  Frame  Buffer 


Feature 


Benefit 


I 
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“  24-bit  color,  1152  x  900  resolution 


SPARCstation  5  TurboGX  Accelerator 

Features 

-  8-bit  accelerated  color 

-  1152  X  900  resolution 

-  772,000  2-D  vectors/sec.  and 
462,000  3-D  vectors/sec. 


-  Lowest-priced  24-bit  imaging  and  fast 
windows 


Benefits 

-  Provides  swift  interactive 
performance  and  optimum 
handling  of  complex  2-D  and 
3-D  wireframe  graphics 


SPARCstation  5  TurboGXplus  Accelerator 


Features 

-  8-bit  accelerated  color 


-  1280  X  1024  resolution 

-  More  than  1.7  million  2-D  vectors/sec. 
and  564,000  3-D  vectors/sec. 


Benefits 

-  Provides  significantly  increased 
2-D  and  3-D  wireframe  graphics 
performance 

-  Supports  high-resolution  monitors 

-  Double-buffered  for  smooth  rendering 
of  complex  wireframe  objects 


SPARCstation  5  ZX  Accelerator 


Features 


Benefits 


24-bit  accelerated  color 
1280  X  1024  resolution, 

350,000  shaded  triangle  mesh/sec., 
750K  3-D  vectors/sec.  130K  shaded, 
lit  quads/sec., 

450K  3D  AA  vectors/sec. 


Fastest  low-cost  3-D  graphics 
performance  in  the  industry 


SPARCstation  5  System:  Low-Cost  Expandable  Package 

Innovative  Packaging 


The  SPARCstation  5  system’s  innovative  package  furnishes  the  foundation  for  the  growth  and  innovation 
that  the  network  needs,  and  saves  desktop  space  as  well. 


Features 


Benefits 


-  409  mm  x  416  mm  x  78  mm 


-  Support  for  up  to  four  internal  devices, 
including  one  or  two  10 -MB /sec.  53 5 -MB, 
1.05-GB  or  2.1-GB  pluggable  internal 
disk  drives 


-  New  design  saves  valuable  desktop  spac 
Indus  try- leading  internal  expansion;  ir 
be  placed  on  the  box 

-  Fast  access  to  more  than  4  GB  of  data 


-  Optional  internal  CD-ROM  drive 


Optional  internal  floppy  disk  drive 


-  Supports  current  and  future  networked 
media  and  other  application  requiremen 

-  Supports  current  and  future  applicatio 
requirements,  such  as  Wabi  and  SunPC 
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software  products 


-  Support  for  up  to  256  MB  of  memory 

-  Three  32-bit  SBus  slots 


-  Two  synchronous  serial  ports 

-  One  parallel  port  (optional  cable  required) 


Easy  to  add  memory  as  requirements  gro 

Industry  standard  bus  provides  for  exp 
allowing  for  requirements  such  as  SunV 
SunATM,  and  SunFastEthernet  adapters 

Ensures  fast  serial  support  for  modems 
and  other  I/O  devices 

Provides  bidirectional  parallel  port  f 
I/O  requirements 


Twisted-pair  Ethernet;  AUI  Ethernet 
(optional  cable  required) 


Built-in  integrated  networking  allows 
easy  connection  into  the  networked  ent 


-  16 -bit  audio,  line  in/ out,  headphone,  and 
microphone 


Offers  high-quality  audio  for  telephon 
digital  media  applications 


SPARCstation  5  System:  Investment  Protection  for  the  Future 


Upgradable  to  a  SPARCstation  20  System 

One  of  the  unique  features  of  the  SPARCstation  5  system  is  that  it  offers  excellent  investment  protection. 
Through  a  simple  board  swap,  the  SPARCstation  5  system  can  be  upgraded  to  the  SPARCstation  20 
desktop  system. 


-  Identical  package  used  for  the 
SPARCstation  5  and  SPARCstation  20 
systems 

-  Simple  board  swap  upgrade  to  a 
SPARCstation  20  system 


Benefits 

-  Offers  excellent  investment  protection; 
same  power  supply,  internal  disk  drives 
CD-ROM,  and  internal  floppy  drive 

-  Provides  a  very  low-cost  path  to  Supers 
hyperSPARC,  and  SuperSPARC-II 
multiprocessing  technologies 


SPARCstation  5  S24  System:  The  Lowest  Cost  24-Bit  Imaging 
Solution  in  the  Workstation  Industry 

SPARCstation  5  S24  Graphics 


The  SPARCstation  5  S24  is  a  new  24-bit  true  color  frame  buffer  that  offers  the  lowest-priced  24-bit 
imaging  solution  in  the  industry.  The  SPARCstation  5  S24  system  provides  competitive  24-bit  graphics 
capabilities  at  the  lowest  cost  in  the  industry,  while  taking  advantage  of  the  network-ready  and 
multitasking  capabilities  found  standard  on  Sun  workstations.  The  SPARCstation  5  S24  offers  new  visual 
computing  capabilities  at  an  exceptional  price/performance  for  a  variety  of  application  areas  that  are 
becoming  increasingly  color-intensive,  including  color  document  imaging,  graphics  design,  color 
publishing,  CIS,  computer-based  education  and  customer  service. 


Features 


Benefits 


24-bit  true  color  output, 
simultaneous  pixel  colors 


16.7  million 


Produces  highest  quality  display  outpu 
Eliminates  color  map  flashing  in  most 
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-  Interfaces  to  64~bit  wide  memory  bus 
instead  of  SBus 


-  Simultaneous  display  of  24-bit  true  color, 
direct  color,  linear  color  (via  gamma 
correction  LUT)  and  8-bit  indexed  color 

-  Acceleration  for  block  copies  and  stipples 


http://www.sun.com/producls-n-solutions/hw/wstns/ss5^Hardware.ht: 


-  High  bandwidth  interface  for  fast  data 
between  system  and  video  memory  provid 
throughput  required  by  2 4 -bit  applicat 

-  Reduces  cost  by  eliminating  the  need  f 
hardware  accelerators 

-  24-bit  color  applications  can  run  simu 
8-bit  color  or  grayscale  applications 


-  Provides  fast  window  and  bitmap  operat 


Go  to  chapter: 

•  Table  of  Contents 

•  Positioning 

•  Software 

•  SPARCserver  5 

•  System  Configurations 

•  Options 

•  Upgrades 

•  Customer  Service 


Questions  or  comments  regarding  this  service?  W€bmaster@su n,  com 
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Sun 


Sun  Announces  Fastest  SPARCstation  20,  SPARCserver  20 


MENLO  PARK,  Calif.,  October  31,  1995-  Continuing  its  drive  to  provide  power  desktop  users  with 
the  best  value  in  the  industry,  Sun  Microsystems  Computer  Company  today  announced  the  fastest 
multiprocessor  and  uniprocessor  systems  in  the  company's  popular  SPARCstation’^'^  20  family  of 
high-performance  workstations. 

The  new  desktops  sport  a  powerful  150  MHz  SPARC™  processor  with  512  Kilobytes  of  cache  and 
provide  a  30  percent  performance  improvement  over  current  SPARCstation  20  systems.  The 
multiprocessor  SPARCstation  20  model  152MP  features  two  150  MHz  SPARC  processors.  The  new 
SPARCstation  20  TurboGX™  model  151  uses  a  single  150  MHz  SPARC  processor.  Yet  it  is  priced  at 
only  $18,995  for  32  megabytes  of  memory,  a  1 -gigabyte  disk  drive  and  20-inch  high-resolution  color 
monitor. 


Sun,  which  holds  more  than  90  percent  of  the  UNIX®  multiprocessing  workstation  market,  is  pricing 
the  new  dual-processor  SPARCstation  20  model  152MP  as  low  as  $25,495. 

The  company  also  unveiled  the  first  desktop  server  based  on  the  150  MHz  SPARC  processor,  the 
SPARCserver™  20  model  151  and  model  152MP,  which  provides  a  30  percent  boost  in  compute  server 

•  performance.  Additionally,  Sun  announced  repricing  of  the  most  popular  SPARCstation  20  and 
SPARCserver  20  systems  by  up  to  15  percent,  as  well  as  new  pricing  for  upgrades  and  SPARC™ 
module  x-options. 

"Our  customers  are  anticipating  the  announcement  of  our  UltraSPARC  systems,"  said  Gene  Banman, 
vice  president  and  general  manager  of  Sun's  Desktop  Systems  Group.  "But  these  new  SPARCstation  20 
desktops  are  another  major  milestone  in  Sun's  ongoing  strategy  to  offer  the  best  value  in  the  industry  to 
power  desktop  users.  The  new  systems,  plus  the  price  reductions  and  upgrade  program  for  current  users, 
emphasize  Sun's  commitment  to  deliver  increasing  performance  while  preserving  the  users'  investments 
in  hardware  and  software,  especially  for  Solaris  1  users." 

The  new  high-end  SPARCstation  20  desktop  is  a  general-purpose  system  designed  for 
performance-conscious  users  running  a  range  of  applications,  including  modeling,  simulation,  MCAD 
and  EDA,  or  any  application  with  compute-intensive  requirements. 


Systems  With  30  Percent  Better  Performance;  Excellent  Upgrade  Options 


The  uniprocessor  SPARCstation  20  model  151  features  169.4  SPECint92  and  208.2  SPECfp92.  The 
dual-processor  SPARCserver  20  model  152MP  features  7310  SPECrate_int92  and  8758  SPECrate_fp92. 


The  SPARCstation  20  TGX  model  151  with  a  150  MHz  SPARC  processor  with  512  Kbytes  of  cache,  32 
Mbytes  of  memory,  expandable  to  512  Mbytes;  a  1  gigabyte  disk  drive,  expandable  to  353  gigabytes; 
four  SBus  expansion  slots,  accelerated  graphics  and  a  20-inch  high-resolution  color  display  sells  for 
$18,995.  The  dual-processor  model  152MP  with  64  Mbytes  of  memory,  a  1  gigabyte  disk  drive,  four 
SBus  slots  and  a  20-inch  color  monitor  sells  for  $25,495.  Comparably  equipped  systems  from 
Hewlett-Packard  list  for  more  than  $21,000  for  a  imiprocessor  system  or  more  than  $34,000  for  a 
multiprocessor  system.  A  comparable  uniprocessor  system  from  SGI  lists  for  more  than  $23,000. 

The  SPARCserver  20  model  151  comes  standard  with  32  Mbytes  of  memory,  one  2.1  gigabyte  internal 
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disk  drive  and  four  SBus  expansion  slots  and  sells  for  $17,495.  The  model  152  with  64  Mbytes  of 
memory  and  two  2.1  gigabyte  drives  sells  for  $28,795. 


The  150MHz  SPARC  MBus  modules  are  fully  compatible  with  current  SPARCstation  20  and 
SPARCstation  10  systems.  Users  simply  replace  their  existing  processor  modules  for  a  30-percent 
performance  increase  while  maintaining  100-percent  binary  compatibility  with  all  their  applications. 


Both  the  SPARCstation  and  SPARCserver  20  model  151  systems  require  the  Solaris™  1.1.2,  Solaris  2.4 
or  later  operating  environment.  The  dual-processor  model  152MP  systems  require  the  Solaris  2.4 
operating  environment.  Price  Reductions  of  15  Percent  In  addition  to  announcing  the  new  workstation 
models.  Sun  has  also  repriced  its  current  SPARCstation  and  SPARCserver  20  families,  as  well  as  system 
upgrades  and  x-options  by  as  much  as  15  percent.  Specifically,  the  price  of  the  SPARCstation  20  model 
71  with  a  20-inch  monitor  has  been  reduced  from  $19,795  to  $16,995,  and  the  price  of  the  model  712MP 
with  a  20-inch  monitor  has  been  lowered  from  $25,295  to  $21,495;  the  price  of  the  model  HS21  with  a 
20-inch  monitor  has  been  reduced  from  $18,995  to  $16,995;  and  the  price  of  the  model  HS22MP  has 
been  reduced  from  $24,495  to  $21,495.  The  new  SPARCstation  20  model  151  and  model  152MP 
desktop  systems,  desktop  servers,  upgrades  and  options  will  be  available  in  December,  1995.  Sun 
Microsystems  Computer  Company  is  a  world  leader  in  the  design,  manufacture  and  sale  of  network 
computing  systems  and  is  a  division  of  Sun  Microsystems,  Inc.  Recognized  for  quality  and  innovation, 
the  company's  SPARC^*^  workstations  and  multiprocessing  servers  each  hold  the  No.  1  UNIX® 
marketshare  position.  These  systems  are  used  primarily  by  businesses,  educational  institutions  and 
governments  worldwide  for  technical,  commercial,  industrial  and  software  development  applications. 


Questions  or  comments  regarding  this  service?  webmasteiiSisun.  com 

Copyright  1996  Sun  Microsystems,  Inc.,  2550  Garcia  Ave.,  Mtn.  View,  CA  94043-1100  USA.  All  rights  reserved. 
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Table  of  Contents 

•  The  SPARCstation  20  System:  The  Networked  UNIX  Desktop  Perfonnance  Leader 

•  Building  on  the  Industry’s  Most  Successful  Desktop 


The  SPARCstation  20  System:  The  Networked  UNIX  Desktop 
Performance  Leader 


K 


The  Industry’s  Highest  Performance  Multiprocessing  Network  Desktop 

The  SPARCstation  20  system  is  the  highest  performance  desktop  system  in  the  industry  —  offering 
unmatched  architecture  and  system  balance,  powerful  multiprocessing,  and  advanced  graphics  and 
imaging.  The  expandability  and  upgradability,  networking,  and  throughput  further  enhance  the 
performance  of  the  SPARCstation  20  system. 

•  The  SPARCstation  20  provides  unmatched  architecture  and  system  balance 

o  Choice  of  powerful  processors:  50-MHz  SuperSPARC,  60-MHz  SuperSPARC,  75-MHz 
SuperSPARC-n,  100-MHz  hyperSPARC(tm),  and  125-MHz  hyperSPARC 
o  MBus:  Separate,  high-speed  CPU  memory  bus 
o  Fast,  large  memory  and  disk  technologies 

•  Powerful  multiprocessing 

o  Two-way  MP  systems  include  Models  502MP,  612MP,  712MP  and  HS22MP 
o  Four- way  MP  systems  include  Models  514MP  and  HS14MP.  The  Model  HS14MP  offers  the 
highest  desktop  compute  performance  available  using  the  SPECrate  industry  benchmark 

•  Advanced  graphics  and  imaging  technologies 
SX  integrated  24-bit  true  color  graphics  and  imaging  standard  on  every  system  —  enabling  the 
world’s  fastest  Adobe  Photoshop  desktop  —  as  demonstrated  at  Siggraph  1994 
Options  for  fast  2-D  8-bit  graphics  acceleration  (TurboGX  and  TurboGXplus(tm)  frame 
buffer)  and  industry-leading  3-D  graphics  (ZX  and  TurboZX  frame  buffer) 
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o  Freedom  series  graphics  accelerators  for  the  highest  performance  3-D  graphics  available  on 
the  market 

•  Industry-leading  expandability  and  upgradability 

o  Modular  processor  and  multiprocessing  design  make  it  easy  to  upgrade  processors.  Expanding 
disk,  memory,  networking,  and  graphics  is  easy  through  the  SPARCstation  20  options 
o  Upgrading  from  the  SPARCstation  5  to  the  SPARCstation  20  is  as  easy  as  swapping  a  board 

•  Industry’s  highest  performance  networking  and  connectivity 

o  Each  SPARCstation  20  has  integrated  twisted-pair  and  AUI  Ethernet,  plus  other  I/O  ports, 
including  serial  and  parallel  ports 

o  Advanced  networking  options  include  100-Mbps  Fast  Ethernet,  ATM,  FDDI,  and  ISDN 

•  Industry’s  fastest  throughput 

o  The  50-MHz  MBus  and  25-MHz  SBus  deliver  more  than  400-MB/sec.  system  throughput, 
providing  industry-leading  system  bandwidth 
o  Enables  advanced  networking  and  growth  to  higher  performance  processors  and 
multiprocessing 

SPARCstation  20  System  Models 

Uniprocessor  systems 


SPARCstation  20 

Entry  Level 

High  Performance 

Model  50 

Model  51 

Model 

61 

Model  71 

Model  HS 

Processor  speed 

50  MHz 

50  MHz 

60  MHz 

75  MHz 

125  MHz 

External  Cache 

None 

1  MB 

1  MB 

1  MB 

256  KB 

No.  of  processors 

One 

One 

One 

One 

One 

MBus /SBus  speed 

50/25  MHz 

50/20  MHz 

50/25 

MHz 

50/25  MHz 

50/25  MH 

SPECint_92 

7  6’.  9 

81.8 

98.2 

125.8 

131.2 

SPECfp_92 

80.1 

89.0 

107.2 

121.2 

153.0 

SPECrate_int92 

1824 

1940 

2329 

2984 

3112 

SPECrate_fp92 

1900 

2111 

2543 

2875 

3629 

Multiprocessor  systems 

SPARCstation  20 

502MP 

612MP  712MP 

HS22MP 

514MP 

HS14MP 

Model 

Processor  speed 

50 

60  75 

125 

50 

100 

(MHz) 

External  Cache 

None 

1  MB  1  MB 

256  KB 

1  MB 

256  KB 

(size/CPU) 

No.  of  processors 

Two 

Two  Two 

Two 

Four 

Four 

MBus /SBus  speed 

50/25 

50/25  50/25 

50/25 

40/20 

50/25 

(MHz) 
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SPECint_92 

NA 

NA 

NA 

NA 

NA 

NA 

SPECfp_92 

NA 

NA 

NA 

NA 

NA 

NA 

SPECrate_int92 

3218 

4492 

5726 

5600 

7072 

8124 

SPECrate_fp92 

3193 

4888 

5439 

6399 

7341 

8906 

Performance  scales  differ  between  the  family  of  SuperSPARC  processor-based  SPARCstation  20  systems 
and  the  new  hyperSPARC  processor-based  SPARCstation  20  systems  due  to  the  different  processor 
performance  characteristics  and  different  processor  cache  memory  design.  The  hyperSPARC 
processor-based  models  should  not  be  positioned  on  SPECmark  performance  or  processor  speed  (MHz) 
numbers  alone. 


The  performance  profile  of  the  hyperSPARC  processor-based  SPARCstation  20  (e.g.  Model  HS21, 
HS22MP,  or  HS14MP)  is  ideally  suited  for  compute-intensive  applications  such  as  design  simulation, 
modeling  and  analysis  applications  that  benefit  from  the  strong  floating-point  performance  and  fast  cache 
memory  design. 

The  SPARCstation  20  Model  71  with  1-MB  SuperCache  is  Sun’s  application  performance  leader  for  3-D 
graphics,  MCAD,  and  general-purpose  power  markets. 

Entry  Markets 


The  SPARCstation  20  offers  advanced  desktop  performance  and  features  for  cost-sensitive  markets. 
No  other  entry  desktop  system  offers  the  integration  of  advanced  technologies  with  the  performance 
and  expansion  capabilities  of  the  SPARCstation  20 

o  Features  the  compute  and  graphics  performance,  multiprocessing,  and  system  expansion 
potential  of  advanced  desktop  technology 

o  Complete  desktop  system  is  superior  to  other  entry-performance  desktop  systems  and  high-end 
PC  systems  (integrated  networking,  advanced  graphics  and  options,  high  disk  and  memory 
capacities) 

o  Offers  SX  24-bit  true  color  graphics  and  imaging,  and  1280  x  1024  resolution  at  entry  prices 


Traditional  Markets 


•  Price/performance  leadership  for  traditional  workstation  requirements 
o  The  industry’s  most  popular  workstation  is  now  more  powerful 

Advanced  Markets 


•  Industry-leading  graphics,  compute,  and  multiprocessing  performance  requirements 
o  Compute  performance  requirements:  The  Power  of  MP 
o  Most  cost-effective  method  to  increase  system  performance 
o  Highest  performance  available  on  the  desktop 
o  Performance  for  advanced  graphics  requirements 


Target  Applications  for  Sun  SPARCstation  Desktop  Systems 
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Positioning 

The  SPARCstation  20  System  at  a  Glance 


Product  Specifications 


Dimensions 

Weight 

CPU 

Architecture 
Cache  on  chip 
External  cache 


SPARCstation  20  and 
SPARCserver  20  systems 

417  mm  x  409  mm  x  77  mm 
12.7  kg 


Multiprocessing 


Memory 
Memory  type 
DRAM  speed 
Bus  width 
SIMM  sizes 

Storage 

Maximum  internal 
Maximum  external 

I/O  architecture 
SBus  slots 
Serial  ports 
Parallel  port 

Networking  ports 


Backup  and  distribution 
Internal 

External 


SuperSPARC  /  SuperSPARC-II 
36  KB  per  CPU 
1  MB  per  CPU 

(except  Models  50  and  502MP) 
Expandable  to  four 


hyperSPARC[l] 

8  KB 
256  KB 

Expandable  to  four 
(100  MHz  only) 


Operating  system 


32  -  512  MB 
ECC 
60  ns 
144  bits 
16,  32,  64  MB 

10-MB/sec.  SCSI 
2.1  GB 

138  GB  with  SPARCstorage  Array 
SBus 

Four  25-MHz  slots [2] 

Two 

One 

Twisted-pair  Ethernet 

AUI  Ethernet  (requires  optional  AUI  adapter  cable) 
Optional  ISDN,  ATM,  FDDI,  Fast  Ethernet 


Optional  3.5-inch  floppy 
Optional  SunCD  2 Plus  drive 
150-MB  .25-inch  tape 
14-GB  8mm  tape 
5.0-GB  4mm  DAT 
20-GB  4mm  DAT  autoloader 
SPARCstorage  Library  Model  8/140 

Solaris®  1.1.1  Version  B  or  1.1.2 [3] 
Solaris  2.3  or  2.4  [4] 


Notes 


1.  Not  available  as  server  configuration 

2.  Models  5 14MP  and  HS 14MP  support  two  SBus  slots 

3.  Model  HS21  requires  Solaris  1.1.2  or  Solaris  2.4;  Hardware  1 1/94  operating  system 

4.  Model  HS22MP  and  HS14MP  requires  Solaris  2.4:  Hardware  1 1/94  operating  system 
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SPARCstation  20  Model  HSll  Specifications 
Performance 


Model 

HS21 

HS22MP 

HS14MP 

Processor (s ) 

1  X  125  MHz 
hyper SPARC 

2  X  125  MHz 
hyper SPARC 

4  X  100  MHz 
hyperSPARC 

SPECint_92 

131.2 

N/A 

N/A 

SPECfp_92 

153 

N/A 

N/A 

SPECrate_int92 

3112 

5600 

8124 

SPECrate_fp92 

3629 

6399 

8906 

Processor 


Architecture 
Memory  management 
Cache 

CPU  interface 


hyper SPARC 

SPARC  reference  MMU  with  4096  contexts 
256  KB 

Two  64-bit  MBus  slots  for  multiprocessing 


Main  Memory 


16- ,  32-,  and  64-MB  SIMM  expansion 
128  MB  maximum  (with  16 -MB  SIMMs) 
256  MB  maximum  (with  32-MB  SIMMs) 
512  MB  maximum  (with  64-MB  SIMMs) 


Standard  Interfaces 


Ethernet 

SCSI 

Serial 

Parallel 

Audio 

SBus 


10-Mb/sec.  twisted-pair  standard  (10-BaseT) : 

AUI  available  with  optional  adapter  cable 
10-MB/sec.  SCSI-2  (synchronous) 

Two  RS-232C/RS423  serial  ports 
Centronics-compatible  parallel  port 
(cable  required) 

16-bit  audio,  8  to  48  kHz;  internal  speaker  and 
external  microphone 

Four  expansion  slots;  64-bit  data  bus  width 
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System  Mass  Storage 


(32-bit  compatible) 


Internal  floppy  disk 


Internal  CD 


Internal  disk 


Optional  3.5-in.  MS-DOS  /  IBM  compatible 
(720  KB,  1.2  MB,  1.44  MB  formatted) 
Optional  644-MB  SunCD  2Plus,  double-speed. 
Photo  CD  compatible 

Up  to  two  3.5-in.  disks  (535  MB  or  1.05  GB 
formatted) 


External  Mass  Storage 


Disk 


535  MB,  1.‘05  GB;  2 . 1  GB  disk  pack; 

4.2  GB  or  8.4  GB  multidisk  pack; 

31.5  GB  or  63  GB  SPARCstorage  Array 

150-MB  .25-in.  QIC-150;  14  GB  Smm  tape; 

5  GB  4mm  DAT;  20  GB  4mm  DAT  auto-loader; 
SPARCstorage  Library  Model  8/140 


Graphics 


SPARCstation  20  (SX) 


Accelerated  24-bit  2-D/3-D  graphics  and  imaging, 
high-speed  convolution,  rotation,  panning, 
zooming,  color  conversion,  24-bit  double 
buffering,  24-bit  Z-buffer,  Gouraud  shading, 
up  to  1280  X  1024  at  76-Hz 


SPARCstation  20 
TurboGX 


8-bit  2-D/3-D  wireframe,  up  to  1152  x  900  at 
76-Hz 


SPARCstation  20 
TurboGXplus 

SPARCstation  20ZX 


8-bit  2-D/3-D  wireframe,  up  to  1280  x  1024  at 
76-Hz,  hardware  double  buffering 

High-performance  3-D  graphics,  24-bit  double 
buffering,  24-bit  Z-buffer,  transparency, 
Gouraud  shading,  nonuniform  rational 
b-splines,  anti-aliasing,  depth  cueing,  up 
to  1280  X  1024  at  76-Hz,  stereo  960  x  680 
at  112-Hz 


SPARCstation  20 
Turbo ZX 


Same  as  above,  plus  up  to  twice  the  graphics 
rendering  performance 


SPARCstation  20M 


SPARCstation  20 

with  Freedom  Series 


Color  camera,  SunVideo  real-time  video 
capture  and  compression,  SX  graphics 

Very  high  performance  3-D  graphics,  Gouraud 
shading,  Phong  shading,  anti-aliasing,  depth- 
cueing,  Alpha  blending,  high-speed  hardware 
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texture  mapping  and  MIP  mapping,  dynamic  pixel 
allocation,  stereo  viewing  option,  video  in/out 
option,  up  to  1536  x  1280  resolution 
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Operating  acoustic 
noise 


Idle  acoustic  noise 


relative  humidity,  noncondensing 
5,4  bels  (at  25°  C) 

5.2  bels  (at  25°  C) 

Declared  noise  emissions  in  accordance  with  ISO  9296 


Regulations 


Safety 

RFI/EMI 

X-ray 


Meets  or  exceeds  the  following  requirements : 

UL  1950,  CSA  950,  TUV  EN  60950 

FCC  Class  B,  DOC  Class  B,  VDE  Class  B,  VCCI 

Class  2 

DHHS  21,  Subchapter  J;  PTB  German  X-ray  Decree 


Dimensions  and  Weight 


SPARCstation  20 
chassis : 


20-in.  color  monitor:  17-in.  color  monitor: 


Height : 
Width : 
Depth: 
Weight : 


7.7  cm  (3.1  in.) 

41.7  cm  (16.4  in. ) 
40.9  cm  (16.1  in. ) 

12.7  kg  (27.0  lb.) 


47.1  cm  (18.5  in. ) 

47.5  cm  (18.7  in. ) 

49.5  cm  (19.5  in.) 

36.5  kg  (80.3  lb.) 


41.4  cm  (16.4  in, ) 

40.6  cm  (16.0  in. ) 
45.0  cm  (17.7  in.) 
25.9  kg  (57.0  lb.) 


Upgrades 


Upgrades  are  available  for  the 

SPARCstation  5,  SPARCstation  10, 
SPARCstation  LX,  SPARCstation  IPX, 
SPARCstation  2,  SPARCstation  1+, 
SPARCstation  1,  and  Sun-3  systems. 


Questions  or  comments  regarding  this  service?  webmaster@sun.com 

Copyright  1996  Sun  Microsystems,  Inc.,  2550  Garcia  Ave.,  Mtn.  View,  CA  94043-1100  USA.  All  rights  reserved. 
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SPARCstation  Desktop  Product  Line  Overview 


Product 

Ultra  1 

Specifications 

Processor (s) 

Model  140 

Model  170 

UltraSPARC-I 

Model  17 OE 

Creator  Series 

Clock  speed 

143  MHz 

167  MHz 

On-chip  Cache  size 
External  cache 

16-KB  I-cache  +  16-KB  D-cache 
512  KB 

SPECint92 (1) 

215 

252 

252 

SPECfp92 (1) 

303 

351 

351 

SPECbase_int92 { 1 ) 

180 

204 

204 

SPECbase_fp92 { 1 ) 

271 

313 

313 

SPECrate_int92 (1) 

5107 

5982 

5982 

SPECrate_fp92 (1) 

7175 

8323 

8323 

SPECrate_base_int92 (1) 

4267 

4893 

4893 

SPECrate_base_fp92 ( 1 ) 

6428 

7403 

7403 

MIPS (1) 

291 

341 

341 

MFLOPS ( 1 ) 

Main  memory 

109 

126 

32  —  512  MB 

126 

Disk  capacity  (SCSI) 

1.05  GB — 147  GB 

Graphics (2) 

TurboGX, 

TurboGX, 

Creator,  Creator3E 

TurboGXplus 

TurboGXplus 

Freedom 

Package  slots 

3  SBus  (32/64-bit, 

3  SBus  (32/64-bit, 

2  SBus  (32/64-bit, 

25-MHz)  connectors 

25-MHz)  connectors 

25-MHz)  connectors 
1  UPA  (83 -MHz) 
connector 

External  Tape  backup 

2.5-GB  QIC,  4-  to 

8 — GB  4— mm,  14— GB  8 

16- 

to  32-  GB  4-nim  auto  loader,  SPARCstorage 

Internal  Data 
interchange/  software 

4-  to 

8-GB  DDS2  4 -mm  tap 
14  GB  8-mm  tape. 

distribution/ backup 
Audio 

3,5 

-inch  floppy,  CD-RC 
16  bit 

Entry  configuration 

32  MB  17-inch 

64  MB  20-inch 

64  MB  17-inch 

TurboGX  color 

TurboGX  color 

Creator  graphics 

1.05  GB  disk 

2.1  GB  disk 

1.05  GB  disk 

Software  licenses (3) 

Solaris 

2.5 

or  later  release 

Product 

Specifications 

SPARC 

Xterminal  1 

SPARCstation  4 
Model  110 

SPARCstation  5 
Model  110 

Processor 

microSPARC 

microSPARC- II 

microSPARC-II 

Clock  speed 

50  MHz 

110  MHz 

110  MHz 

Cache  size 

6  KB 

24  KB 

24  KB 

External 

None 

None 

None 
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SPECint92 (1) 

N/A 

78.6 

78.6 

SPECfp92 (1) 

N/A 

65.3 

65.3 

SPECbase_int92 (1) 

N/A 

68.7 

68.7 

SPECbase_fp92 (1) 

N/A 

63.0 

63.0 

SPECrate_ 
int92 (1) 

N/A 

1864 

1864 

SPECrate 
fp92 (2) 

N/A 

1549 

1549 

SPECrate_base_int92 (1) 

N/A 

1630 

1630 

SPECrate_base_fp92 (1) 

N/A 

1494 

1494 

MIPS 

N/A 

135.5 

135.5 

MFLOPS  (1) 

N/A 

21.7 

21.7 

Main  memory 

8-128  MB 

32-160  MB 

32-256  MB 

Disk  capacity 
(SCSI) 

N/A 

1.05  -  56GB 

1.05-92GB 

Graphics2 , 5 

8-bit 

accelerated  color 
TurboGX , TurboGX  Plus 

8-bit 

pixel- accelerated 
color 

S 2 4, TurboGX, 
TurboGXplus , 
SPARCstation  5Z 

Package 

slots 

N/A 

1  SBus 
connector 

3  SBus 
(22  MHz) 
connectors 

Tape  backup 

N/A  1 - =-=— 

2.5GB  .25-in.,  5-GB  4mm,  ==z=====:===:= 

14-GB  8mm,  20-GB  4mm  auto  loader 

240 -GB  SPARCstorage  Library 

Data 

interchange/ 

software 

distribution 

CD-ROM 

3 . 5-in. 
floppy 

CD-ROM 

3 . 5-in 
floppy 

CD-ROM 

Infrared  (IR) 

Audio 

None 

16  bit 
optional 

16  bit 

Base 
conf ig. 

8  MB 

15-in.  color 

16  MB 

15-in.  color 

535-MB  disk 

32  MB 

17-in. 

TurboGX  color 

1.05GB  disk 

Software 

licenses 

3,4 

X-terminal 

Software 

Version  2.1, 

Display 

Postscript 

Solaris  1.1.2 

Solaris  2.4  Hardware: 

11/94  or 
later  release 

• 

Product 

SPARCsta 

t  i  o  n  2  0 
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Specs 


Model  50 

Model  51 

Model  61 

Model  71 

Model 

Processor (s ) 

1  SuperSPARC+ 

1  Supers PARC+ 

1  SuperSPARC+  1  SuperSPARC-II 

1  hyp 

Clock  speed 

50  MHz 

50  MHz 

60  MHz 

75  MHz 

125  M 

Cache  size 

36  KB 

36  KB 

36  KB 

36  KB 

8  KB 

External 

cache 

N/A 

1  MB 

1  MB 

1  MB 

256  KB 

SPECint92 

(1) 

76.9 

81.8 

98.2 

125.8 

131.2 

SPECfp92 

(1) 

80.1 

89.0 

107.2 

121.2 

153 

SPECbase_ 
int92 (1) 

71.2 

75.3 

90.8 

116.4 

122.4 

SPARCbase_ 
fp92 (1) 

74.2 

81.2 

98.1 

109.4 

142.3 

SPECrate_ 
int92 (1) 

1824 

1940 

2329 

2984 

3112 

SPECrate 

fp92(l) 

1900 

2111 

2543 

2875 

3629 

SPARCrate_base_ 

int92{l) 

1689 

1786 

2154 

2761 

2903 

SPARCrate_base_ 

1760 

1926 

2327 

2595 

3375 

MIPS  {2± 

134.2 

133.0 

167.4 

204.7 

243.2 

MFLOPS  (2) 

30.5 

30.5 

36.6 

44.4 

51.4 

Main  memory 

32-512  MB 

Disk  capacity 
(SCSI) 

1  GB  -  353  GB 

Graphics  (3) 

24 

-bit  color. 

SX, 

SPARCstation  20  ZX, 

TurboGX ,  TurboGXplus , 

1=========  TurboZX,  Freedom  Series  =  =  =  =  = 


Package 

4  SBus 

4  SBus 

4  SBus 

4  SBus 

4  SBus 

slots 

(25  MHz) 

(20  MHz) 

(25  MHz) 

(25  MHz) 

(25  MH 

connectors 

connectors 

connectors 

connectors 

connec 

Tape  backup 


2.5GB  .25-in.,  5-GB  4mm 
14 -GB  8mm,  20-GB  4mm  auto  loader 
1========  SPARCstorage  Library  Model  =  = 


Data 

interchange/ 

software 

distribution 


3. 5 -in.  floppy 
CD-ROM 
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Audio 

16 

bit 

Base  color 
config. 

32  MB 
17-in.  SX 
color 

1-GB  disk 

32  MB 

17-in.  SX 
color 

1-GB  disk 

32  MB  17-in. 
TurboGX  color 

1-GB  disk 

32  MB  17-in. 
TurboGX  color 

1-GB  disk 

32  MB 

TurboG 

1-GB  d 

Software 

licenses 

(3) 

Solaris  2.3  or  later  release 
(Solaris  1.1.1  Version  B  Optional) 

So 

Product 

Specs 

Model  502MP 

S  P  A  R  C  s  t 

712MP 

a  t  i  o  n  2 

HS22MP 

0 

152MP 

514 

Processors 

2 

SuperSPARCH- 

2 

SuperSPARC-II 

2 

hyper SPARC 

2 

hyperSPARC 

4 

Sup 

Clock  speed 

50  MHz 

75  MHz 

125  MHz 

150  MHz 

50 

Cache  size 

36  KB/CPU 

36  KB/CPU 

8  KB/CPU 

8  KB /CPU 

36 

External 

cache 

N/A 

1  MB/CPU 

256  KB/CPU 

512  KB/CPU 

1  M 

SPECrate_ 

int92(l) 

3218 

5726 

5600 

7310 

707 

^  SPECrate_ 

fp92(l) 

3193 

5439 

6399 

8758 

734 

SPARCrate_ 
base_int92 (1) 

2984 

5332 

5347 

7004 

633 

SPARCrate_ 
base_fp92 ( 1 ) 

2978 

4923 

6046 

7945 

670 

Main  memory 

32-512  MB 

64-512  MB 

64-512  MB 

64-512  MB 

64- 

Disk 

capacity 

1  GB 
353 

GB 

(SCSI) 

Graphics  24-bit 

(2)  color,  SX, 

SPARCstation 

20ZX, 

TurboGX, 

TurboGXplus , 

TurboZX, 

Freedom  Series 

Package  4  SBus  4  SBus  4  SBus  2  SBus  4 

slots  (25  MHz)  (25  MHz)  (25  MHz)  (25  MHz)  (2 

connectors  connectors  connectors  connectors  co 


2.5  GB  .25-in. 

5-GB  4mm 
14-GB  8mm 

20-GB  4mm  auto  loader 
140-GB  SPARCstorage  Library 
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Data 

interchange 
/  software 
distribution 


3.5-in. 

floppy 

CD-ROM 


Audio  16  bit 


Base  color 
conf ig . 

32  MB  17-in. 

TurboGX 

color 

1-GB  disk 

64  MB  20-in. 

TurboGX 

color 

1-GB  disk 

64  MB  20- in. 

TurboGX 

color 

1-GB  disk 

64  MB  20-in. 

TurboGX 

color 

1-GB  disk 

64 

Tu 

CO 

1- 

Software 
licenses 
(4) , (5) 

Solaris  2.3 
or  later 
release 

Solaris  2.3 
or  later 
release 

Solaris  2.4 
or  later 
release 

Solaris  2.4 
or  later 
release 

So 

or 

re 

Notes: 


(1)  SMCC  SPEC92,  Dhrystone  1.1  MIPS  and  Unpack  1000  Double  Precision  results  use  the  Apogee 
compilers  from  Apogee  Software  with  a  Kuck  &  Associates  preprocessor. 

(2)  Check  price  list  for  system  configurations. 

(3)  Solaris  2.x  system  license  is  included. 


(4)  SPARCstation  5  S24  configurations  require  Solaris  2.3  HAV:  8/94.  Solaris  1.x  is  not  supported  on 
SPARCstation  5ZX  or  S24  configurations. 


(5)  XMarks  1.8  -  3.05,  and  Xstones  8 IK  -  199K. 


Questions  or  comments  regarding  this  service?  webmaster@sun.com 

Copyright  1996  Sun  Microsystems,  Inc.,  2550  Garcia  Ave.,  Mtn.  View,  CA  94043-1100  USA.  All  rights  reserved. 
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The  SPARCserver™  SPARCserver  5  and  SPARCserver  20  give  your  workgroup  outstanding 
performance  in  all  your  critical  application  areas.  You'll  have  the  power  to  run  databases,  increase 
file-sharing  throughput,  offload  printing  tasks,  and  run  any  of  more  than  10,000  SPARC(R)  solutions, 
from  accounting  to  electronic  design  packages.  These  systems  can  also  open  up  network  resources  to  all 
your  PC  and  Macintosh(R)  users,  whether  they  are  using  Novell(R)  NetWare(R),  Banyan  VINES,  or 
AppleTalk(R)  software. 

Designed  for  distributed  computing,  these  compact,  high-capacity  servers  run  the  Solaris(R)  operating 
environment.  Robust  and  feature-rich,  Solaris  is  the  leading  32-bit  UNIX(R)  solution  and  delivers  the 
highest  networking  performance  in  the  industry. 


Moreover,  Solstice^^  Enterprise  Management  Solutions  give  system  administrators  a  full  range  of  tools 
to  keep  the  network  running  at  peak  efficiency:  Solstice  JumpStart™  for  automatic  software 
distribution.  Solstice  AdminSuite^”^  for  managing  user  accounts,  host  names,  printers,  and  serial  ports. 
Solstice  PC  Management:  SolarNet'*''^  PC-Admin  software  to  automatically  add  new  PC  clients  and 
extend  consistent  security  and  administrative  policies.  And  OpenBoot^’^  for  plug-and-play  support  of 
new  system  options. 


You  can  also  employ  comprehensive  system  and  network  management  software— from  Sun  and  other 
industry-leading  sources— to  ensure  high  data  availability  and  protection.  Sun's  Solstice  DiskSuite™ 


provides  volume  management  to  protect  against  disk  failures,  and  a  journaling  file  system  for  fast 
recovery.  Sun  servers  running  Solaris  system  software  are  robust  and  reliable— proven  in  thousands  of 


production  environments. 


Cost-effective  growth. 


As  compact  as  these  servers  are,  they  offer  you  plenty  of  capacity.  Each  starts  with  32  MB  of  memory 
and,  depending  on  which  model  you  choose,  can  expand  to  160,  256,  or  5 12  MB. 

What's  more,  these  desktop  servers  have  substantial  internal  capacity  for  disk,  floppy,  and  CD-ROM 
drives.  The  SPARCserver  5  and  SPARCserver  20  can  accommodate  up  to  two  internal  disks  for 
additional  storage,  and  both  provide  plenty  of  SBus  I/O  expansion  for  additional  peripherals  or  network 
connections. 


We  also  offer  innovative  storage  solutions  such  as  the  SPARCstorage  Array  series.  These  disk-array 
subsystem  enhance  your  server  with  an  unmatched  combination  of  storage  capacity,  performance,  high 
availability,  and  manageability-all  for  a  surprisingly  low  price. 

With  the  SPARCserver  20  system,  adding  processing  power  is  economical,  too.  Because  its  processors 
reside  on  separate  MBus  modules,  you  can  easily  add  up  to  two  or  four  processors  per  system.  More 
CPUs  enable  your  server  to  handle  multiple  tasks  simultaneously,  whether  it's  separate  database  queries, 
multiple  file  requests,  or  even  a  multithreaded  compute-intensive  application.  Another  advantage  of  our 
modular  design:  upgrading  to  next-generation  processors  is  extremely  simple  and  cost-effective. 


If  this  much  expandability  isn't  enough,  we  offer  an  easy  growth  path  to  our  UltraServer  family  of 
workgroup  servers  or  to  the  more  powerful  departmental  or  datacenter  servers. 
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Incomparable  support 


To  ensure  your  SPARCserver  systems  continue  to  give  the  reliable  performance  you’ve  come  to  expect, 
SunService  offers  a  full  range  of  support  options  from  basic  telephone  support  to  round-the-clock 
coverage  for  mission-critical  applications.  You  pick  the  level  of  support  that's  right  for  your  business, 
confident  that  you're  backed  by  the  industry's  largest  base  of  dedicated  UNIX  experts. 


Questions  or  comments  regarding  this  service?  webmasterdbsun. com 

Copyripht  1996  Sun  Microsystems,  Inc.,  2550  Garcia  Ave.,  Mtn.  View,  CA  94043-1100  USA.  All  rights  reserved. 
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SPARCserver  5  Positioning 


Overview 


The  SPARCserver  5  is  a  robust,  cost-effective,  expandable  workgroup  server,  with  enough  room  to  grow 
with  a  customer's  workgroup.  The  SPARCserver  5  is  designed  for  workgroups  of  10  to  40  users  with  an 
average  of  25  GB  of  disk  storage.  It's  perfect  as  a  workgroup,  file,  print,  application,  or  connectivity 
server  to  PC  LAN  or  file  service  environments. 


With  the  right  combination  of  I/O  peripherals  (disk,  tape,  and  CD-ROM)  and  software  packages  such  as 
Solstice™  PC  Management,  SolarNet'^'^  PC-Admin’^'^,  and  PC-NFS’^'^;  the  SPARCserver  5  can  become 
an  affordable  and  powerful  gateway  to  LAN  or  file  service  environments. 


As  a  workgroup  LAN,  the  SPARCserver  5  system  enables  PC  and  workstation  clients  to  access  and 
share  files.  It  also  offers  internal  LAN  communication  and  administration,  and  the  ability  to  share  other 
network  resources,  such  as  printers. 


Key  Facts 


The  SPARCserver  5  Model  1 10  is  built  around  the  1 10-MHz  microSPARC-II  processor  and 
comes  preconfigured  with  a  CD-ROM  drive. 

The  SPARCserver  5  is  designed  around  a  fast  64-bit  memory  bus  and  fast  microSPARC-II 
processor  CPU  (1 10-MHz). 

The  SPARCserver  5  provides  greater  expandability  than  the  SPARCserver  4,  with  over  50  percent 
more  memory  capacity  (256  MB  maximum),  over  three  times  the  total  disk  storage  capacity  (107 
GB  maximum),  and  three  times  the  network  connectivity  (three  SBus  slots). 

Entry  configurations  of  the  SPARCserver  5  system  start  with  32  MB  of  memory  and  2.1-GB  disk 
storage  capacity.  In  addition,  the  SPARCserver  5  system  comes  with  a  host  of  built-in  features: 
o  Three  SBus  slots 
o  Two  synchronous  serial  ports 
o  One  parallel  port 

o  SCSI  and  Ethernet  (twisted-pair  and  AUI)  ports 

o  Support  for  up  to  four  internal  devices  (including  up  to  two  disks,  one  floppy  drive,  and  one 
CD-ROM  drive 

o  Eight  SIMM  slots  for  added  memory  capacity  (8-MB  or  32-MB  SIMMs) 

Networking  connectivity  support  includes  token  ring,  high-speed  serial  interface,  SBus 
Prestoserve,  SBus  Fast  SCSI/Buffered  Ethernet,  SBus  SCSL/Buffered  Ethernet,  serial  parallel 
controller,  ISDN,  Fast  Ethernet,  ATM,  FDDI,  SCSI  host  adapter,  and  SBus  Quad  Ethernet. 
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Operating  system  support  includes  Solaris  1.1.1  version  B  or  higher,  and  Solaris  2.3  Edition  II  or 
later  releases. 

A  Solaris  2.x  server  license  comes  standard  with  every  SPARCserver  5  system. 

The  SPARCserver  5  system  can  be  easily  upgraded  to  the  SPARCserver  20  system  with  a  simple 
board  swap.  ^ 


Questions  or  comments  regarding  this  service?  wehmaster(a)sun. com 
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Sun 


SPARCserver  20  Positioning 


Overview 


The  SPARCserver  20  system  is  Sun's  most  affordable  multiprocessing  server,  providing  new  levels  of 
performance  and  storage  scalability  all  within  a  single  box. 


The  SPARCserver  20  is  designed  for  medium  sized  workgroups  of  40  to  70  users  with  an  average  of  50 
GB  of  disk  storage.  The  power  and  scalability  of  the  SPARCserver  20  make  it  the  ideal  solution  to 
handle  database  applications,  increase  small  or  mid-size  workgroups'  file-sharing  throughput,  off-load 
printing  tasks,  and  run  any  of  more  than  10,000  Solaris(R)  solutions,  ranging  from  spreadsheets  to  CAD 
packages. 


The  SPARCserver  20  system  is  perfect  as  a  high-performance  connectivity  server,  giving  PC  and 
Macintosh  systems  access  to  applications  and  resources  in  other  departments,  anywhere  on  the  network. 


Key  Facts 


The  SPARCserver  20  delivers  high  performance  from  a  well-balanced  design  that  includes  fast 
system  (50-MHz  MBus)  and  I/O  (25-MHz  SBus)  bus  architectures,  and  highly  scalable 
SuperSPARC-lF'^  or  hyperSPARC  processors. 

The  SPARCserver  20  provides  even  greater  scalability  and  investment  protection  than  the 
SPARCserver  5,  with  over  100  percent  more  memory  capacity  (512  MB  maximum),  a  144  percent 
increase  in  disk  storage  capacity  (339  GB  maximum),  33  percent  more  network  connectivity  (four 
SBus  slots),  and  allowance  for  multiprocessing  scalability.  In  addition,  the  SPARCserver  20 
comes  standard  with  CD-ROM  and  optional  floppy  drive  capabilities. 

The  SPARCserver  20  includes  generous  room  for  growth,  with  storage  capacities  ranging  from  1 
to  339  GB,  using  the  latest  in  storage  technology-Sun's  SPARCstorage  Array. 

o  The  SPARCstorage  Array  is  built  around  a  25-MB/sec.  full-duplex  Fibre  Channel  interface, 
providing  throughput  superior  to  even  fast/wide,  half-duplex,  20-MB/sec.  SCSI. 

The  SPARCserver  20  Models  are  built  around  two  different  processor  speeds: 
o  75-MHz  SuperSPARC-II:  Models  71  and  712MP 
o  1 50-MHz  SuperSPARC:  Models  151  and  152MP 
Entry  configurations  on  the  SPARCserver  20  system  start  with 

o  Uniprocessor  configurations:  32  MB  of  memory  and  2-GB  disk 
o  Multiprocessor  configurations:  64  MB  of  memory  and  two  2-GB  disks 
Standard  features  on  the  SPARCserver  20  system  include  four  SBus  slots,  two  synchronous  serial 
ports,  one  parallel  port,  SCSI  and  Ethernet  (twisted-pair  and  AUI)  ports,  support  for  up  to  four 
internal  devices  (including  up  to  two  535-MB,  1.05-GB,  or  2.1-GB  pluggable  disk  drives),  and 
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eight  SIMM  slots  for  added  ECC  memory  capacity  (16-,  32-,  and  64-MB  60-ns  SIMMS) 
Networking  connectivity  support  includes  Token  Ring,  high-speed  serial  interface,  SBus  and 
NVRAM  Prestoserve™,  SBus  Fast  SCSI/Buffered  Ethernet,  SBus  SCSI/Buffered  Ethernet,  Serial 
Parallel  Controller,  ISDN,  Fast  Ethernet,  ATM,  FDDI,  SCSI  host  adapter,  and  SBus  Quad 
Ethernet. 

Operating  system  support  includes  Solaris'^'^  1.1.1  Version  B  or  higher  and  Solaris  2.3  Hardware: 
5/94  or  later  release. 

With  a  simple  SuperSPARC-II  module  swap,  users  can  easily  upgrade  to  faster  and  higher 
performing  processors  within  the  SPARCserver  20  product  family. 

A  Solaris  2.x  server  license  comes  standard  with  every  SPARCserver  20  system.  Every  server 
license  comes  bundled  with  Solaris  2.x  System  Administrator  AnswerBook,  Solstice  AdminSuite, 
Solstice™  Backup™,  and  Solstice’’"'^  DiskSuite"^^  products,  which  are  included  as  part  of  the 
Solaris  2.x  product. 


Questions  or  comments  regarding  this  service?  webmaster(S)sun.com 

Copyright  1996  Sun  Microsystems,  Inc.,  2550  Garcia  Ave.,  Mtn.  View,  CA  94043-1100  USA.  All  rights  reserved. 
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